Шел 2005-ый год. Мой интерес к разработке системы управления контентом на Java для компании, недавно купившей наш стартап, неуклонно улетучивался, в то время как моей настоящей страстью была разработка компиляторов и инструментов языковой инфраструктуры (в основном для SBCL). Как-то раз я заметил открытую вакансию как-раз по этому направлению, что вообще-то было достаточно редким явлением. Я быстро прошел интервью — настолько быстро, что даже не задал нужных вопросов и проигнорировал несколько тревожных звоночков.
Меня ожидало захватывающее путешествие в мир ретрокомпьютинга.
Начало странностей
Итак, это был бывший отдел разработки внутренних инструментов очень большой компании, назовём её Х. По некоторым причинам Х отделила данный отдел и продала его среднего размера консалтинговой компании, назовём её Y. Итак, я собирался работать на Y. Они искали людей, разбирающихся в компиляторах, чтобы они взяли на себя поддержку их собственного компилятора языка С (не только компилятора, но еще и линкера, ассемблера и т.д.). Я неверно их понял, поскольку думал, что этот набор они унаследовали от Х. Но это было не так. Компилятор пришел из ещё одной большой компании, назовём её Z, которая прекратила его поддержку. Тогда Х купила исходные коды у Z за очень большие деньги, и отдала Y чтобы та, наконец, что-то с этим всем поделала. На самом деле это был даже не один набор инструментов, а целых два. Ух, даёшь ещё больше компиляторов!
Я начал работать в сентябре, но какие-то графики поломались и ещё целый месяц или два у нас не было работы. У меня было достаточно времени для акклиматизации. И это было хорошо, потому что с момента, когда я ступил в это здание у меня появилось ощущение, что я странным образом переместился в параллельную вселенную, где сейчас начало 80-ых годов. Ну, знаете, тот случай, когда вам нужно найти некоторую старую документацию и в конце-концов вы её находите внутри древней самописной системы контроля версий, написанной поверх RCS.
В первый же рабочий день я обнаружил, что компания Х использует, вероятно, самый большой кластер VAX в мире для сборки своего продукта. Да, дюжины VAX под VMS, работающих как компилирующая ферма, создающая x86-код. Зачем вообще этой компании понадобилось иметь собственный компилятор С? Ну, у них существовал их собстенный внутренний невероятный язык программирования, который вы можете представить, если подумаете об императивном Erlang с синтаксисом Pascal. Программы на этом языке компилировались в код на С, для сборки которого и нужен был собственный компилятор С. Я не знаю сколько кода было написано на этом их невероятном внутреннем языке, но по моим оценкам — где-то миллионов 10 строк кода минимум.
Зачем же в этом процессе был нужен собственный компилятор С? Компиляция С-кода давала бинарники, которые затем могли запускаться только на (конечно же!) их собственной внутренней невероятной операционной системе, которая была написана в конце 80-ых. Эта операционная система использовала сегментные регистры 386-го процессора для эмуляции многопоточности и пересылки сообщений. Для поддержки всего этого им был нужен компилятор со значительно более «умной» работой с сегментными регистрами, чем это бывает в обычных компиляторах. Вы можете спросить насколько вообще разумно полагаться на сегментные регистры в 2005-ом году, когда работа с ними становится всё медленнее и медленнее с каждым новым поколением процессоров, а в x86-64 их поддержка и вовсе прекращается. А вы не волнуйтесь насчёт этого! В компании существовал параллельный проект по переносу всего этого кода на Solaris.
После нескольких месяцев сидения сложа руки и изучения всей этой загадочной инфраструктуры в наш отдел разработки компиляторов пришла посылка. Мы ожидали исходники. Но постойте, почему указано, что для переноски требуется 2 человека? Они что их — распечатали?!
Ах, если бы всё было так просто! Это был аж целый сервер, который мы должны были использовать для сборки компилятора, когда получим его исходный код. Это был компьютер с процессором 80286, работающий на операционной системе Intel Xenix 286 3.5. Единственным способом обмениваться с этим поразительным воплощением мощи вычислительных технологий был последовательный порт, работающий на скорости 9600 bps. К счастью, предыдущие владельцы этого сервера были достаточно добры, чтобы установить на его огромный 40-мегабайтный жесткий диск Kermit, так что мне хотя бы не нужно было возиться с дискетами. Боже, каким же поразительным куском древней истории были эта машина и её операционная система!
Вы можете спросить, было ли мудрым решение использовать машину 15-20 летней давности в качестве единственного способа сборки приложения — она ведь неизбежно рано или поздно сломается. Я даже поднял эту проблему и предложить сделать образ жесткого диска и попробовать запустить его в виртуальной машине. Эту идею отклонили, поскольку машина была старой и хрупкой, мы не могли рисковать, разбирая её и делая образ диска — его в случае чего было бы очень сложно заменить. Когда предыдущие владельцы искали это железо по антикварным магазинам, они нашли всего два до сих пор работающих экземпляра на всю страну.
Сейчас самое время сказать, что я, вообще-то, стрелянный воробей. Меня вырастили волки на сервере SunOS 4, на котором я позже администрировал учётки нескольких сотен пользователей. Моя персональная почта в 2005-ом году работала через UUCP. Мои прошлые выходные (сейчас, в 2015-ом) прошли за попыткой сборки частично отсутствующих исходников интерпретатора Lisp, написанных ещё до моего рождения. В общем, вы понимаете, что я питаю уважение к старым компьютерам и программам.
Но даже по моим стандартам уровень компьютерной археологии в проекте разработки этого компилятора был запредельным. И, как оказалось позже, я ещё не достиг дна кроличьей норы.
Спустя ещё несколько недель наконец приехали исходники. Они были написаны на PL/M. (Подождите, это вообще язык программирования? Да нет, вы шутите, правда?). А последняя дата модификации исходников была в 80-каком-то году. Инструкция по сборке проекта была напечатана на печатной машинке. Не на принтере. Некоторые компоненты не собирались и требовали правки make-файлов. Жесткого диска не хватало для одновременной сборки всех компонентов, так что весь процесс сборки выглядел так:
- Загрузить исходник компонента на сервер через последовательный порт (вы помните, 9600 bps)
- Распаковать архив
- Собрать
- Скачать результат
- Удалить
- Повторить всё вышеуказанное для пяти остальных компонентов
Один только процесс загрузки кода каждого компонента занимал час. И всё же после длительного бодания мне удалось собрать всё это так, что получившиеся бинарники до бита совпали с теми, что были собраны 20 лет назад и использовались всё это время.
Было ужасно сложно вообще понять зачем мы делаем то, что делаем. Не было никакой документации на этот код, кроме пары листиков с инструкцией по сборке — нам приходилось использовать реверс-инжиниринг буквально на каждом шагу. При передаче кода не было никаких тренингов, семинаров. Да и вообще трудно представить, что спустя 20 лет в компании Z всё ещё работал кто-то, имевший отношение к разработке этого кода в 80-ых. Никто в нашей команде не знал PL/M. От изменения строки кода до сборки бинарника и его запуска уходил минимум 1 час. Отладчика не было вообще. Хотите добавить вывод одного отладочного printf (ну или как там оно в PL/M называлось) — добавляйте и ждите 1 час, пока код соберётся. Эта разработка была просто чистой болью.
Спустя месяц я выразил руководству свои опасения и мне было сказано не волноваться:
-А, так мы вообще и не планируем вносить изменения в этот компилятор, с его помощью собирается относительно мало кода. Вот другой, который мы вскоре получим, более современен и мы сконцентрируемся на нём.
-Что? Я только что месяц кусал себе локти в попытках выучить PL/M и Xenix/286, работая через Kermit-соединение со скоростью 9600 bps, а вы сейчас говорите мне, что это нам не пригодиться?
-Да. Мы просто хотели убедиться, что получили всё, за что заплатили.
Я даже не знал, стоит мне больше сожалеть об убитом зря времени, или радоваться тому, что больше не придётся возиться в этом болоте.
Грустная часть
Здесь заканчивается забавный раздел причудливого ретрокомпьютинга. Теперь мы переходим к грустной части — дисфункциональности корпоративных политик. Если вы начали читать эту статью просто чтобы посмеяться, можете сразу переходить к концу.
Мы получили исходники второго компилятора. Он тоже не выглядел бодрым молодцем. Собирался он под Visual Studio 6. Ни документации, ни тестов. Отсутствие тестов нам объяснили претензиями на их код со стороны третьей фирмы. Отсутствие документации нам не объяснили никак.
Этот компилятор было легко собрать. Но что мы могли с ним сделать? Я перечитал его код, попытался понять, что делается в каждом файле, сделал несколько экспериментов и написал кое-какие заметки. Затем мы собрали большое совещание с ведущими инженерами всех отделов компании Х, где использовался данный компилятор. Целью было выяснить, что нам необходимо улучшить. Совещание было невероятно демотивирующим. Половина участников придерживались мнения, что лучше ничего не трогать, чтобы не дай бог ничего не сломать. Некоторые были смелее, но и они не могли вспомнить какой-либо важной функциональности, которой им бы нехватало. Затем кто-то пожалел меня и сказал, что текущий компилятор не очень хорошо планирует загрузку сегментных регистров и это бьёт по производительности. Может быть мы могли бы это улучшить?
После совещания один из менеджеров сказал мне, что это вообще-то наша работа — предлагать проекты, которые могли бы помочь нашему заказчику. И это должны быть не какие-то минорные улучшения, а чётко сформулированные и спланированные задачи, эффективность внедрения которых можно было бы измерить в долларах и она должна покрывать все операционные затраты на разработку, да ещё и приносить какую-то прибыль. Нельзя не отметить абсолютное безумие подобного способа разработки компилятора, но это то, что от нас требовалось. Как вообще в компании Х кто-то предполагал, что из этого всего получится что-то хорошее — для меня загадка.
Но не обращайте внимание на всё это. Наш изначальный проект по передаче поддержки двух компиляторов изначально был достаточно хорошо профинансирован, а задачи его сформулированы так расплывчато, что нам не составило труда аргументированно доказать, что улучшения являются важной частью основных задач проекта. У нас по крайней мере было то самое единственное улучшение, к которому хотя бы кто-то выразил интерес.
Итак, я реализовал дополнительный этап оптимизации для сегментных регистров, и даже получил одобренное ревью кода от авторов компилятора, когда они приезжали к нам из компании Z на тренинг. Оно вроде бы работало, но, как я уже говорил выше, у нас не было набора тестов, а создать такой для компилятора — немалая работа (Отлично! Мы можем предложить это как целый новый проект!).
Мы не могли проверить наши улучшения на настоящем коде, поскольку для этого требовалась та самая «невероятная собственная операционная система» компании Х. Единственным способом получить некоторые замеры производительности и доказательства корректности работы было планирование работы в лаборатории компании Х. Проходили недели и недели в попытках добиться выделения нам одновременно времени в лаборатории и людей из компании Х, которые были нужны для тестов. Это, конечно, понятно — им было по большому счёту всё-равно, выйдет новая версия нашего компилятора или нет, у них были их основные рабочие задачи, не касающиеся этого. Но для нас-то было важно показать, что сделанные нами изменения полезны и корректны. Мы действительно повысили производительность, но без конкретных цифр этого нельзя было доказать.
В этот момент меня, наконец, осенило пониманием того, что никакой реальной работы всё это время у меня не было. Все эти особенные компиляторы станут ненужны, как только компания Х мигрирует с их невероятной собственной ОС, что когда-нибудь да случится. О, конечно, они всё ещё должны будут «поддерживаться» на случай, если вдруг в какой-нибудь программе 20-летней давности обнаружится баг и будет нужен фикс. Но в общем вкладываться в разработку нового функционала при ограниченности оставшегося времени жизни всей этой системы было катастрофически нерентабельно. Компания абсолютно точно потратила на покупку и поддержку этого проекта семизначную сумму (в долларах), но сделала ли она что-то полезное с этим кодом? Нет.
Всё это предполагалось поддерживать вечно, в то время как через 5 лет всё будет заменено на совершенно новые системы. Но ничего не будет выброшено, нет. Всё будет накапливаться и накапливаться, требуя поддержки вечно. И вы будете держать в общем-то неплохих инженеров, способных разрабатывать компиляторы, чтобы делать эту безумную работу, вместо того, чтобы работать на переднем крае науки в высокотехнологичных компаниях.
И как это всё вообще может закончиться? Я представил себя на собеседовании где-то лет через пять, в 2010-ом, пытаясь объяснить потенциальному работодателю, как мои знания Xenix, PL/M и VMS могут быть полезны в разработке его продукта. В жизни инженера может настать период, когда его перестанет тянуть к новым технологиям, но позволить случиться этому с тобой в 20 лет — не самое подходящее время :)
Финал
Я уволился даже без предварительного поиска нового места работы — просто надеялся, что что-нибудь да подвернётся. В подтверждение моей интуиции, после моего заявления об увольнении но ещё до фактического ухода компания ITA Software написала в листе рассылки SBCL, что хотела бы нанять кого-то для работы над улучшением SBCL, что вообще-то выглядело работой моей мечты в то время. Очень удачно всё сложилось.
Вот и всё. В комментариях вы можете рассказать о своём опыте разработки нового ПО на чём-то вроде IBM 1401 прямо сейчас, в 2015-ом году, ну или что-то в таком же духе ;-)
Комментарии (41)
Gorthauer87
14.09.2015 13:13+6Нда, мое наростающее неудовольство тем, что мне нельзя с++11 использовать кажутся детским лепетом по сравнению с этим. Хотя на мозг точно также давит даже юзание технологий 5 10 летней давности без возможности развития.
phprus
14.09.2015 15:01+2На мой взгляд у С++11 еще долго будут сложности с массовым внедрением.
Слишком долго его пилили в компиляторах, слишком часто ломалась совместимость ABI, а когда в GCC 5 ABI изменили окончательно, то не обновили SOVERSION, а добавили дефайн, который будет включать/выключать совместимый ABI при компиляции. И не дай бог попадутся при линьковке две библиотеки, у которых этот дефайн будет в разных значениях — все развалится :(
В прошлом году на эту тему была дискуссия на хабре: http://habrahabr.ru/post/245175/#comment_8168683
mapron
14.09.2015 18:23Да, я теперь уже согласен с теми комментаторами =) Все течет, все меняется.
phprus
14.09.2015 18:51+1У меня в одном проекте, который должен был быть переносим между компиляторами (в том числе от Intel) и дистрибутивами, была попытка внедрить С++11, но все разбилось о сложность обеспечения совместимости всего и вся и о баги компиляторов разных версий в реализации новых и не совсем фич. (Переносимость/совместимость нужна была в том числе бинарная).
Так и живет тот проект на С++98/03 и gcc 4.3.4 из SLE 11, зато проблем c совместимостью пока не было.
Думаю, когда в массовых LTS дистрибутивах появится GCC 5, стандарт С++11 начнет использоваться активнее (или более новый стандарт, который будет к тому времени полностью реализован), правда RHEL6,7 и SLE11,12 еще долго будут тянуть за собой наследие несовместимостей в GCC 4/5.mapron
14.09.2015 18:56Да, что там, я до сих пор пару GCC 3.4 + 4.0 поддерживаю для наших железяк =( Ну, по крайней мере, компилится boost.
Halt
14.09.2015 19:16Меряться, так меряться :D У нас на одной из платформ GCC 4.2.0. Из «новых фич» там есть tr1 :) Буст компилится, но использовать его нельзя. Ну, почти…
А на другой да, 3.4 видимо. Самое печальное в таких ситуациях не в том что поддерживать приходится экскременты мамонта, а в том что развивать их дальше как правило невозможно.
Компилятор идет вместе с SDK от вендора (да, это встраиваемая железка). Вендор эту версию похоронил миллион лет назад. Печаль и безысходность.mapron
14.09.2015 19:20Кхм) это еще что, мы GCC 3.4 сами собирали с uclibc. А сама MOXA так вообще с ней 2.95 давала! (и это 2013 год!).
Так что я думаю это общая проблема всех вендорных железяк.phprus
14.09.2015 19:49Ох! В моей жизни самым древним компилятором был GCC 3.4.6(вроде шесть, но не помню точно) под Solaris 10. И я им Boost собирал до рабочего состояния, правда с патчами.
GCC 4.1.2 из RHEL 5 выпилился в прошлом году вместе с RHEL 5 и теперь самый древний из используемых мною компиляторов — GCC 4.3.4 из SLE11 (тоже для свежего Boost приходится некоторые патчи держать).
Видимо хорошо, что в моей жизни нет встраиваемых железок, только сервера, а то такая некромантия действительно может вызывать уныние.
Gorthauer87
14.09.2015 18:56Обидно, что на прошлом месте работы я уже успел полностью к нему привыкнуть. В целом, это к крайне неприятным мыслям приводит.
0xd34df00d
14.09.2015 19:07Среди критериев выбора места работы можно и разрешённые инструменты учитывать, например.
Alexeyslav
14.09.2015 13:43с PL/M сталкивался, в институте… на нем была написана программа для решения заданий по рассчетным работам. Да еще для экономии места записали её чуть ли не одной строчкой текста. Переменные все названы 1-2 буквами, поди разберись с ходу что куда идёт.
На работе еще говорили что расчет зарплаты написан именно на PL/M и к тому времени как я работал последний разработчик этой программы умер лет как 5 назад.
До недавнего времени этот монстр работал в продуктиве в эмуляторе ЭВМ ЕС-какой-тотам (не помню точной серии). К сожалению, я даже не видел кода этой программы.
UA3MQJ
14.09.2015 16:08К счастью, а не к сожалению! У нас вот был этот эмулятор, под названием «примус»… Я сам любитель ретрокомпьютинга, но пакетный способ работы — ИМХО совершенно бесчеловечен.
khdavid
14.09.2015 14:21Судя по профилю автора в линкедине, компания в которой он работал ITA Software
speakingfish
14.09.2015 19:27+7Мои пять копеек: В конторе X потеряли исходники древнего компилятора своего языка, на котором работала вся прикладная логика. В результате система хоть и работала на современных компьютерах, но прикладной код компилировался компилятором, работающим ещё под DOS. Потеря исходников долгое время скрывалась, а после обнаружения пропажи попытки реверс инженеринга за приемлемое время успехом не увенчались. На дальнейшие попытки и воссоздание компилятора с нуля ресурсы не выделили. Зато с клиентов можно было получать деньги на оптимизацию, в рамках которой большая часть прикладной логики постепенно мигрировала в хранимые процедуры. В дальнейшем первопричина разработки толстого прикладного слоя в хранимых процедурах была забыта и всем новым программистам просто объявляли о таком стиле, как о стандарте разработки, принятом в компании: «Почему? Потому что тут так принято....
RolexStrider
14.09.2015 22:28+1Восхитительно! Особенно сначала зацепило что «Инфопульс Украина», а потом — «Перевод». И вот это: «почему указано, что для переноски требуется 2 человека?» Сразу подумалось: «А почему не восемь и костюмы химзащиты?» (я про ртутные линии задержки подумал)
ToSHiC
14.09.2015 23:39+3У меня, конечно, намного лайтовее вариант, но тоже ничего так. Пришёл работать в московский офис большой международной компании. Код написан на C и COBOL (ну и ещё немного PRO*C в data layer), суммарно несколько миллионов строк. Сборка производится тулчейном на основе перловый скриптов и мейкфайлов, которые суммарно тянут на несколько мегабайт. Серверная часть работает под управлением WeblogicTuxedo, который появился ещё до того, как славную компанию BEA кто-то там купил. Клиентская часть — на PowerBuilder, самая моя любимая часть в том коде это разбросанные по коду строки:
if (win16) ...
Пока пишешь прикладной код, который нужен бизнесу, всё неплохо. Следуешь гайдам, фигачишь код, коммитишь в RCS (опять же своим набором скриптов, конечно же), тестируешь — и готово. Но однажды пришёл запрос на запил single signon — чтобы пользователь аутентифицировался в одном приложении, а во всех остальных входил в систему автоматически. Оказалось, что в компании из 15+ тысяч человек про взаимодействие клиентских приложений, Tuxedo и ядра системы знает 3 (дада, три) человека. Они присылали нам патчи в код, который последний раз менялся в 1994 (кажется) году.
Скажу честно, это было одно из самых интересных заданий для меня за все те 3 года, что я проработал в той конторе. Разобраться в коде, понять, как вся эта фигня работает, а затем предлагать свои улучшения… Определённо, у меня был повод для гордости.
darthslider
15.09.2015 11:27+1У нас на работе какая-то бортовая авионика обсчитывается на допотопном VAX. Своих специалистов естественно нет, если что-то надо — вызывают дедушку лет 80 который что-то там шаманит. Лет несколько назад на нём умер блок питания, заказывали из США, отдел закупок проклял всё в процессе.
Почему используется? Потому что а) работает — не трогай. б) у коллег — из Америки используются такие же.
По той же причине стоят офисы 2003 у одной из лабораторий, но это не самые динозавры конечно.
Еще используется хитрая среда разработки Native, которая работает только на XP SP2. Вероятно есть новая версия, но платить за неё не хотят. Под это дело даже отдельный изолированный домен с 20 раб. станциями выделен.
Весело!
potan
15.09.2015 12:11Ностальгия…
Я бы пожалуй за такую работу взялся, в долгоживущих системах есть что-то привлекательное. Не случайно в «Глубине в небе» Винджа одной из самых востребованных профессий была профессия «программист-архиолог».
chernish2
18.09.2015 06:26+1На мой вкус, статья не столько о археопрограммизме (хотя, конечно, технические подробности зачаровывают), сколько о невменяемости процессов внутри крупных компаний. Я и сам в такой работал, в Москве. На собеседовании все казалось приличным и заманчивым — милая девушка-HR, просившая рисовать треугольники и квадратики для психологической оценки моей личности, фраза будущего руководителя «ну вот на наши курсы Oracle мы тебя и отправим, а Java ты и так знаешь» (при том, что ни одного вопроса на знание этой самой Java задано не было).
По факту выяснилось, что делать на рабочем месте мне решительно нечего. В течение трех месяцев я либо проходил обучение за счет компании (это было действительно интересно — новый для меня на тот момент PL/SQL, вкусный обед за счет компании, и домой), либо откровенно пинал балду. При этом руководство требовало ежемесячных отчетов о занятости по часам (иначе заработная плата не выплачивалась), поэтому (по инструкции руководителя, рабочее место которого, кстати, находилось в 130км от нашего офиса) я писал отчеты в стиле «Развертывание сервера Weblogic — 2 недели, написание парсера XML-страницы — 2 недели.
Не выдержал, через 3 месяца сбежал.darthslider
18.09.2015 10:53Жесть какая. Был схожий опыт, тоже 3 месяца проработал, хотя там изначально понимал, что временно сюда устроился, пока ищу что-то «нормальное». Делать абсолютно нечего, при этом заниматься чем-то своим нельзя. Даже книжку просто не почитать.
vitaly_KF
20.09.2015 22:47+1Может не поймёте, но по моему Вам повезло на этом месте. Я всегда работал в компаниях и на должностях, где у меня не было отдыха больше получаса в день. Постоянно есть огромное количество задач. от которых порой просто хочется просто выключиться. А по вечерам — кодинг собственных небольших проектов. Всегда мечтал поработать на таком вот месте — деньги тебе платят, по задачам ты отчитываешься, а сам пилишь себе стартап. мобильное приложение или фрилансишь по тихому. Расскажите. неужели это не вариант?
chernish2
08.10.2015 22:43Вариант конечно. Могу в личку название компании прислать.
Но мне все же больше нравится мое нынешнее положение — сам себе хозяин. Работаю тогда, когда хочу (ну и сколько реально требуется), в остальное время свободен, и не надо никого обманывать и делать вид.
pcmaniac
06.10.2015 19:42+1Шёл 2014-й год, одна крупная структура покупает для своих нужд один небольшой банк. Банк едет на АБС (автоматизированная банковская система), написанной в 1997г на Delphi. Фирма-разработчик до сих пор существует т.к. у неё на поддержке остался один клиент — тот самый банк. Мне предлагают взять проект в свои руки и допилить под наши нужды, для этого вполне реально купить или разработчика целиком или исходники с правами. Дали мне немного потрошков на изучение и о-боже! Всё что можно сделать для усложнения поддержки и замедления работы было сделано. Но чтобы система хоть как-то жила на том железе, под которое разрабатывалось, они не оптимизировали запросы, структуру БД или сам код. Они переписали СУБД! У них фактически самописный эмулятор оракла с несколькими дополнительными фичами, сильно ускоряющими основную часть запросов (ввиду специфики самих этих запросов). В общем после глубокого изучения системы, решили не пинать труп, а купить современную АБС (кстати, тоже написанную на Delphi) и переехать на неё. Сейчас банк едет на современном софте, современном железе и его АБС активно поддерживается и допиливается разработчиком.
Мораль сей басни такова: если фирме нужна эффективность, она будет её искать, а если нужно только сохранение статуса кво, то мы долго ещё будем сталкиваться с крупными системами, работающими в эмуляторе, работающем в эмуляторе, работающем в эмуляторе, потому что железа такого давно уже нет, исходники утрачены и языка никто не знает.tangro
06.10.2015 23:20Какой-то прям заповедник Delphi. Ну ладно в 1997-ом, но в 2014-ом то откуда?
Wedmer
07.10.2015 03:11Так он теперь еще кросскомпиляторами под разные оси обзавелся и вроде стал генерить 64 битный код.
Скорее всего у конторы -разработчика он на легальном положении и обновляется периодически.pcmaniac
08.10.2015 21:59Там под Win32/64 работает нативный компилятор, а под OS X, iOS, Android через LLVM. Разница во времени сборки очень заметная, один и тот же проект под Win64 у меня собирается 10-15 сек, а под Android 2-3 минуты. Основное время занимает даже не сама сборка, а линковка, но это уже детали. Зато единая кодовая база под все платформы — это реально круто и экономит кучу времени и денег.
pcmaniac
08.10.2015 21:55+1Ну если язык/среда/библиотека/фреймворк/ОСь (подчеркнуть нужное) не снискало популярности у школьников, это ещё не значит что он(она, оно, они) не подходит для решения прикладных задач. Есть разные продукты, которые нацелены на решение разных задач. Да, на Delphi нет смысла разрабатывать OSS, по одной простой причине: среда закрытая и платная (судьбу Lazarus я тут поминать в суе не буду, она застряла в глубоких 90х). Хотя большинство коммерческих компонентов поставляются именно в исходных кодах, как и компоненты/библиотеки, идущие в комплекте со средой. Delphi — это RAD, нацеленный на решение определённого круга задач и с ними он справляется отлично. Мне лично нравится простота языка. Я могу в голове удержать довольно сложный проект, чего не могу сказать о других языкаъ/средах. Ну и имея определённые наработки можно довольно быстро, как из кирпичиков, собрать довольно сложный проект. Да, спецы своего дела, «имеющие определённые наработки», скажут что они также это могут сделать и посредством других инструментов, каждому своё. Как по мне, так на Delphi легко не только собрать, но и поддерживать, допиливать, разбираться в чужом, особенно если качественно написано. Очень часто приводят примеры «говнокода» как доказательство несостоятельности инструмента, но это палка о двух концах: если порог вхождения низкий — противники будут жаловаться на большое кол-во говнокода, если высокий — на то, что «хрен разберёшься». Тут как и везде: кто хочет — делает, а кто не хочет, ищет причины.
norguhtar
10 из 10 археологов :)
hungry_ewok
Это даже не археология, это уже геология какая-то…
ls1
Палеонтология
hungry_ewok
Ну, палеонтология все-таки может иметь дело с сохранившейся органикой, вроде мамонтов. А тут даже не просто окаменелые кости, это вообще под мантию разок ныряло. ;)
Acuna
Скорее всего персонал ходит там во всем черном, как в крематории)
gurinderu
некрофилия)