Comments 42
10 из 10 археологов :)
Это просто хоррор какой-то.
Нда, мое наростающее неудовольство тем, что мне нельзя с++11 использовать кажутся детским лепетом по сравнению с этим. Хотя на мозг точно также давит даже юзание технологий 5 10 летней давности без возможности развития.
На мой взгляд у С++11 еще долго будут сложности с массовым внедрением.
Слишком долго его пилили в компиляторах, слишком часто ломалась совместимость ABI, а когда в GCC 5 ABI изменили окончательно, то не обновили SOVERSION, а добавили дефайн, который будет включать/выключать совместимый ABI при компиляции. И не дай бог попадутся при линьковке две библиотеки, у которых этот дефайн будет в разных значениях — все развалится :(
В прошлом году на эту тему была дискуссия на хабре: http://habrahabr.ru/post/245175/#comment_8168683
Слишком долго его пилили в компиляторах, слишком часто ломалась совместимость ABI, а когда в GCC 5 ABI изменили окончательно, то не обновили SOVERSION, а добавили дефайн, который будет включать/выключать совместимый ABI при компиляции. И не дай бог попадутся при линьковке две библиотеки, у которых этот дефайн будет в разных значениях — все развалится :(
В прошлом году на эту тему была дискуссия на хабре: http://habrahabr.ru/post/245175/#comment_8168683
Да, я теперь уже согласен с теми комментаторами =) Все течет, все меняется.
У меня в одном проекте, который должен был быть переносим между компиляторами (в том числе от Intel) и дистрибутивами, была попытка внедрить С++11, но все разбилось о сложность обеспечения совместимости всего и вся и о баги компиляторов разных версий в реализации новых и не совсем фич. (Переносимость/совместимость нужна была в том числе бинарная).
Так и живет тот проект на С++98/03 и gcc 4.3.4 из SLE 11, зато проблем c совместимостью пока не было.
Думаю, когда в массовых LTS дистрибутивах появится GCC 5, стандарт С++11 начнет использоваться активнее (или более новый стандарт, который будет к тому времени полностью реализован), правда RHEL6,7 и SLE11,12 еще долго будут тянуть за собой наследие несовместимостей в GCC 4/5.
Так и живет тот проект на С++98/03 и gcc 4.3.4 из SLE 11, зато проблем c совместимостью пока не было.
Думаю, когда в массовых LTS дистрибутивах появится GCC 5, стандарт С++11 начнет использоваться активнее (или более новый стандарт, который будет к тому времени полностью реализован), правда RHEL6,7 и SLE11,12 еще долго будут тянуть за собой наследие несовместимостей в GCC 4/5.
Да, что там, я до сих пор пару GCC 3.4 + 4.0 поддерживаю для наших железяк =( Ну, по крайней мере, компилится boost.
Меряться, так меряться :D У нас на одной из платформ GCC 4.2.0. Из «новых фич» там есть tr1 :) Буст компилится, но использовать его нельзя. Ну, почти…
А на другой да, 3.4 видимо. Самое печальное в таких ситуациях не в том что поддерживать приходится экскременты мамонта, а в том что развивать их дальше как правило невозможно.
Компилятор идет вместе с SDK от вендора (да, это встраиваемая железка). Вендор эту версию похоронил миллион лет назад. Печаль и безысходность.
А на другой да, 3.4 видимо. Самое печальное в таких ситуациях не в том что поддерживать приходится экскременты мамонта, а в том что развивать их дальше как правило невозможно.
Компилятор идет вместе с SDK от вендора (да, это встраиваемая железка). Вендор эту версию похоронил миллион лет назад. Печаль и безысходность.
Кхм) это еще что, мы GCC 3.4 сами собирали с uclibc. А сама MOXA так вообще с ней 2.95 давала! (и это 2013 год!).
Так что я думаю это общая проблема всех вендорных железяк.
Так что я думаю это общая проблема всех вендорных железяк.
Ох! В моей жизни самым древним компилятором был GCC 3.4.6(вроде шесть, но не помню точно) под Solaris 10. И я им Boost собирал до рабочего состояния, правда с патчами.
GCC 4.1.2 из RHEL 5 выпилился в прошлом году вместе с RHEL 5 и теперь самый древний из используемых мною компиляторов — GCC 4.3.4 из SLE11 (тоже для свежего Boost приходится некоторые патчи держать).
Видимо хорошо, что в моей жизни нет встраиваемых железок, только сервера, а то такая некромантия действительно может вызывать уныние.
GCC 4.1.2 из RHEL 5 выпилился в прошлом году вместе с RHEL 5 и теперь самый древний из используемых мною компиляторов — GCC 4.3.4 из SLE11 (тоже для свежего Boost приходится некоторые патчи держать).
Видимо хорошо, что в моей жизни нет встраиваемых железок, только сервера, а то такая некромантия действительно может вызывать уныние.
Обидно, что на прошлом месте работы я уже успел полностью к нему привыкнуть. В целом, это к крайне неприятным мыслям приводит.
Брат по несчастью. ;-(
с PL/M сталкивался, в институте… на нем была написана программа для решения заданий по рассчетным работам. Да еще для экономии места записали её чуть ли не одной строчкой текста. Переменные все названы 1-2 буквами, поди разберись с ходу что куда идёт.
На работе еще говорили что расчет зарплаты написан именно на PL/M и к тому времени как я работал последний разработчик этой программы умер лет как 5 назад.
До недавнего времени этот монстр работал в продуктиве в эмуляторе ЭВМ ЕС-какой-тотам (не помню точной серии). К сожалению, я даже не видел кода этой программы.
На работе еще говорили что расчет зарплаты написан именно на PL/M и к тому времени как я работал последний разработчик этой программы умер лет как 5 назад.
До недавнего времени этот монстр работал в продуктиве в эмуляторе ЭВМ ЕС-какой-тотам (не помню точной серии). К сожалению, я даже не видел кода этой программы.
Захватывающий триллер! Благо, что с хэппи эндом
Судя по профилю автора в линкедине, компания в которой он работал ITA Software
Мои пять копеек: В конторе X потеряли исходники древнего компилятора своего языка, на котором работала вся прикладная логика. В результате система хоть и работала на современных компьютерах, но прикладной код компилировался компилятором, работающим ещё под DOS. Потеря исходников долгое время скрывалась, а после обнаружения пропажи попытки реверс инженеринга за приемлемое время успехом не увенчались. На дальнейшие попытки и воссоздание компилятора с нуля ресурсы не выделили. Зато с клиентов можно было получать деньги на оптимизацию, в рамках которой большая часть прикладной логики постепенно мигрировала в хранимые процедуры. В дальнейшем первопричина разработки толстого прикладного слоя в хранимых процедурах была забыта и всем новым программистам просто объявляли о таком стиле, как о стандарте разработки, принятом в компании: «Почему? Потому что тут так принято....
Восхитительно! Особенно сначала зацепило что «Инфопульс Украина», а потом — «Перевод». И вот это: «почему указано, что для переноски требуется 2 человека?» Сразу подумалось: «А почему не восемь и костюмы химзащиты?» (я про ртутные линии задержки подумал)
У меня, конечно, намного лайтовее вариант, но тоже ничего так. Пришёл работать в московский офис большой международной компании. Код написан на C и COBOL (ну и ещё немного PRO*C в data layer), суммарно несколько миллионов строк. Сборка производится тулчейном на основе перловый скриптов и мейкфайлов, которые суммарно тянут на несколько мегабайт. Серверная часть работает под управлением WeblogicTuxedo, который появился ещё до того, как славную компанию BEA кто-то там купил. Клиентская часть — на PowerBuilder, самая моя любимая часть в том коде это разбросанные по коду строки:
Пока пишешь прикладной код, который нужен бизнесу, всё неплохо. Следуешь гайдам, фигачишь код, коммитишь в RCS (опять же своим набором скриптов, конечно же), тестируешь — и готово. Но однажды пришёл запрос на запил single signon — чтобы пользователь аутентифицировался в одном приложении, а во всех остальных входил в систему автоматически. Оказалось, что в компании из 15+ тысяч человек про взаимодействие клиентских приложений, Tuxedo и ядра системы знает 3 (дада, три) человека. Они присылали нам патчи в код, который последний раз менялся в 1994 (кажется) году.
Скажу честно, это было одно из самых интересных заданий для меня за все те 3 года, что я проработал в той конторе. Разобраться в коде, понять, как вся эта фигня работает, а затем предлагать свои улучшения… Определённо, у меня был повод для гордости.
if (win16) ...
Пока пишешь прикладной код, который нужен бизнесу, всё неплохо. Следуешь гайдам, фигачишь код, коммитишь в RCS (опять же своим набором скриптов, конечно же), тестируешь — и готово. Но однажды пришёл запрос на запил single signon — чтобы пользователь аутентифицировался в одном приложении, а во всех остальных входил в систему автоматически. Оказалось, что в компании из 15+ тысяч человек про взаимодействие клиентских приложений, Tuxedo и ядра системы знает 3 (дада, три) человека. Они присылали нам патчи в код, который последний раз менялся в 1994 (кажется) году.
Скажу честно, это было одно из самых интересных заданий для меня за все те 3 года, что я проработал в той конторе. Разобраться в коде, понять, как вся эта фигня работает, а затем предлагать свои улучшения… Определённо, у меня был повод для гордости.
У нас на работе какая-то бортовая авионика обсчитывается на допотопном VAX. Своих специалистов естественно нет, если что-то надо — вызывают дедушку лет 80 который что-то там шаманит. Лет несколько назад на нём умер блок питания, заказывали из США, отдел закупок проклял всё в процессе.
Почему используется? Потому что а) работает — не трогай. б) у коллег — из Америки используются такие же.
По той же причине стоят офисы 2003 у одной из лабораторий, но это не самые динозавры конечно.
Еще используется хитрая среда разработки Native, которая работает только на XP SP2. Вероятно есть новая версия, но платить за неё не хотят. Под это дело даже отдельный изолированный домен с 20 раб. станциями выделен.
Весело!
Почему используется? Потому что а) работает — не трогай. б) у коллег — из Америки используются такие же.
По той же причине стоят офисы 2003 у одной из лабораторий, но это не самые динозавры конечно.
Еще используется хитрая среда разработки Native, которая работает только на XP SP2. Вероятно есть новая версия, но платить за неё не хотят. Под это дело даже отдельный изолированный домен с 20 раб. станциями выделен.
Весело!
Ностальгия…
Я бы пожалуй за такую работу взялся, в долгоживущих системах есть что-то привлекательное. Не случайно в «Глубине в небе» Винджа одной из самых востребованных профессий была профессия «программист-архиолог».
Я бы пожалуй за такую работу взялся, в долгоживущих системах есть что-то привлекательное. Не случайно в «Глубине в небе» Винджа одной из самых востребованных профессий была профессия «программист-архиолог».
На мой вкус, статья не столько о археопрограммизме (хотя, конечно, технические подробности зачаровывают), сколько о невменяемости процессов внутри крупных компаний. Я и сам в такой работал, в Москве. На собеседовании все казалось приличным и заманчивым — милая девушка-HR, просившая рисовать треугольники и квадратики для психологической оценки моей личности, фраза будущего руководителя «ну вот на наши курсы Oracle мы тебя и отправим, а Java ты и так знаешь» (при том, что ни одного вопроса на знание этой самой Java задано не было).
По факту выяснилось, что делать на рабочем месте мне решительно нечего. В течение трех месяцев я либо проходил обучение за счет компании (это было действительно интересно — новый для меня на тот момент PL/SQL, вкусный обед за счет компании, и домой), либо откровенно пинал балду. При этом руководство требовало ежемесячных отчетов о занятости по часам (иначе заработная плата не выплачивалась), поэтому (по инструкции руководителя, рабочее место которого, кстати, находилось в 130км от нашего офиса) я писал отчеты в стиле «Развертывание сервера Weblogic — 2 недели, написание парсера XML-страницы — 2 недели.
Не выдержал, через 3 месяца сбежал.
По факту выяснилось, что делать на рабочем месте мне решительно нечего. В течение трех месяцев я либо проходил обучение за счет компании (это было действительно интересно — новый для меня на тот момент PL/SQL, вкусный обед за счет компании, и домой), либо откровенно пинал балду. При этом руководство требовало ежемесячных отчетов о занятости по часам (иначе заработная плата не выплачивалась), поэтому (по инструкции руководителя, рабочее место которого, кстати, находилось в 130км от нашего офиса) я писал отчеты в стиле «Развертывание сервера Weblogic — 2 недели, написание парсера XML-страницы — 2 недели.
Не выдержал, через 3 месяца сбежал.
Жесть какая. Был схожий опыт, тоже 3 месяца проработал, хотя там изначально понимал, что временно сюда устроился, пока ищу что-то «нормальное». Делать абсолютно нечего, при этом заниматься чем-то своим нельзя. Даже книжку просто не почитать.
Может не поймёте, но по моему Вам повезло на этом месте. Я всегда работал в компаниях и на должностях, где у меня не было отдыха больше получаса в день. Постоянно есть огромное количество задач. от которых порой просто хочется просто выключиться. А по вечерам — кодинг собственных небольших проектов. Всегда мечтал поработать на таком вот месте — деньги тебе платят, по задачам ты отчитываешься, а сам пилишь себе стартап. мобильное приложение или фрилансишь по тихому. Расскажите. неужели это не вариант?
Вариант конечно. Могу в личку название компании прислать.
Но мне все же больше нравится мое нынешнее положение — сам себе хозяин. Работаю тогда, когда хочу (ну и сколько реально требуется), в остальное время свободен, и не надо никого обманывать и делать вид.
Но мне все же больше нравится мое нынешнее положение — сам себе хозяин. Работаю тогда, когда хочу (ну и сколько реально требуется), в остальное время свободен, и не надо никого обманывать и делать вид.
Вы ошибаетесь, такая «работа» сложна психологически и похожа на «до полудня выкапываем яму, после полудня закапываем», да, если ты не глупец ты начинаешь искать профит и например тратишь время на самообразование, запил чего то своего, но это все не то, нет челенджа, самостоятельного роста, увеличения полезного круга знакомств и удовлетворения от работы.
Шёл 2014-й год, одна крупная структура покупает для своих нужд один небольшой банк. Банк едет на АБС (автоматизированная банковская система), написанной в 1997г на Delphi. Фирма-разработчик до сих пор существует т.к. у неё на поддержке остался один клиент — тот самый банк. Мне предлагают взять проект в свои руки и допилить под наши нужды, для этого вполне реально купить или разработчика целиком или исходники с правами. Дали мне немного потрошков на изучение и о-боже! Всё что можно сделать для усложнения поддержки и замедления работы было сделано. Но чтобы система хоть как-то жила на том железе, под которое разрабатывалось, они не оптимизировали запросы, структуру БД или сам код. Они переписали СУБД! У них фактически самописный эмулятор оракла с несколькими дополнительными фичами, сильно ускоряющими основную часть запросов (ввиду специфики самих этих запросов). В общем после глубокого изучения системы, решили не пинать труп, а купить современную АБС (кстати, тоже написанную на Delphi) и переехать на неё. Сейчас банк едет на современном софте, современном железе и его АБС активно поддерживается и допиливается разработчиком.
Мораль сей басни такова: если фирме нужна эффективность, она будет её искать, а если нужно только сохранение статуса кво, то мы долго ещё будем сталкиваться с крупными системами, работающими в эмуляторе, работающем в эмуляторе, работающем в эмуляторе, потому что железа такого давно уже нет, исходники утрачены и языка никто не знает.
Мораль сей басни такова: если фирме нужна эффективность, она будет её искать, а если нужно только сохранение статуса кво, то мы долго ещё будем сталкиваться с крупными системами, работающими в эмуляторе, работающем в эмуляторе, работающем в эмуляторе, потому что железа такого давно уже нет, исходники утрачены и языка никто не знает.
Какой-то прям заповедник Delphi. Ну ладно в 1997-ом, но в 2014-ом то откуда?
Так он теперь еще кросскомпиляторами под разные оси обзавелся и вроде стал генерить 64 битный код.
Скорее всего у конторы -разработчика он на легальном положении и обновляется периодически.
Скорее всего у конторы -разработчика он на легальном положении и обновляется периодически.
Там под Win32/64 работает нативный компилятор, а под OS X, iOS, Android через LLVM. Разница во времени сборки очень заметная, один и тот же проект под Win64 у меня собирается 10-15 сек, а под Android 2-3 минуты. Основное время занимает даже не сама сборка, а линковка, но это уже детали. Зато единая кодовая база под все платформы — это реально круто и экономит кучу времени и денег.
Ну если язык/среда/библиотека/фреймворк/ОСь (подчеркнуть нужное) не снискало популярности у школьников, это ещё не значит что он(она, оно, они) не подходит для решения прикладных задач. Есть разные продукты, которые нацелены на решение разных задач. Да, на Delphi нет смысла разрабатывать OSS, по одной простой причине: среда закрытая и платная (судьбу Lazarus я тут поминать в суе не буду, она застряла в глубоких 90х). Хотя большинство коммерческих компонентов поставляются именно в исходных кодах, как и компоненты/библиотеки, идущие в комплекте со средой. Delphi — это RAD, нацеленный на решение определённого круга задач и с ними он справляется отлично. Мне лично нравится простота языка. Я могу в голове удержать довольно сложный проект, чего не могу сказать о других языкаъ/средах. Ну и имея определённые наработки можно довольно быстро, как из кирпичиков, собрать довольно сложный проект. Да, спецы своего дела, «имеющие определённые наработки», скажут что они также это могут сделать и посредством других инструментов, каждому своё. Как по мне, так на Delphi легко не только собрать, но и поддерживать, допиливать, разбираться в чужом, особенно если качественно написано. Очень часто приводят примеры «говнокода» как доказательство несостоятельности инструмента, но это палка о двух концах: если порог вхождения низкий — противники будут жаловаться на большое кол-во говнокода, если высокий — на то, что «хрен разберёшься». Тут как и везде: кто хочет — делает, а кто не хочет, ищет причины.
Sign up to leave a comment.
Самая устаревшая инфраструктура, которую только можно купить за деньги