Как стать автором
Обновить

Комментарии 334

Грустная история, на самом деле. История о полезном коде, который надо бы транслировать подо что-то современное, но для этого надо выучить ещё и это капризное современное.

И тот полезный код превращается в чемодан без ручки -- тащить неудобно, а выкинуть жалко.

Так досадно, что так и не появилось надёжных средств автоматической миграции с D7 куда-нибудь в RAD Studio! Вот не понимаю, это такая сложная задача, или просто сообщество уже вымерло и никому это неинтересно?

Кобол и фортран старше, но они живы.

Они не являлись "языком одной корпорации"

А Object Pascal когда стал таким языком? Из того что активно развивается сейчас: минимум 2 свободных и 2 коммерческих реализации сразу на ум приходят.

Первый ОО Pascal Борланда был турбо 5.5. MS в это же время выпустил свой (названия не помню). Продукты столкнулись. В Byte-en про это большую статью напечатали. Борландовский победил. А У.Гейтс очень обиделся на Pascal.

У MS был Quick Pascal.
И вроде после появления TP 5.5, максимум 6.0, Microsoft из этой гонки вышел.

TurboPascal существовал и продавался за сотню баксов в середине 80-х еще до возникновения Борланда. Эту контору уже после построили Нильс Йенсен (в большей степени программист, нежели барыга) и Филипп Кан (в большей степени барыга, нежели программист) вокруг этого самого турбопаскаля. Следующим шагом взросления компании был турбо модула и си-компилятор. И тут случилось интересное. Кан решил убить Turbo Modula-2, чтобы тот не создавал конкуренции трубопаскалю, а также купить сторонний компилятор, который он позже назовет TurboC, в то время как в недрах самой Борланд людьми Йенсена разрабатывался свой. В результате Кан и Йенсен разошлись. Йенсен выкупил у Борланд все свои компиляторы и увел команду в контору Jensen&Partners Int., которая выпустила TopSpeed C, modula-2, Clarion и даже ассемблер. В те времена для PC основными с-компиляторами (в порядке роста качества генерируемого кода) были турбоси (борланд), msc 6.0 (микрософт) и topspeed (JPL), соответственно, с обратной популярностью. За ними шли с/с++ компиляторы от Semantec и Watcom. Topspeed C/C++ среди всех отличался крайне быстрой компиляцией, малым размером сгенерированного кода и высокой его производительностью. Народ, который писал нa С++ и был вынужден из-за политики своей компании программировать на микрософте или борланде, выпускал на них только релизы — вся разработка велась на TopSpeed C, что позволяло, как минимум, сэкономить время на ребилде проекта. Борланд турбо паскаль, как и турбоси имели кучу проблем а рантайме. Одна из наиболее тяжелых — кривое отслеживание дискет в приводе и последующая ее порча в случае замены. Собственно, все, что касалось int 13h, было реализовано кривейшим образом, либо вообще никак.

В 90% случаев с d7 можно безболезненно мигрировать на Lazarus, совместимость куда выше чем с новыми версиями radstudio

Так досадно, что так и не появилось надёжных средств автоматической миграции с D7 куда-нибудь в RAD Studio!

Тут скорее не появилось желания мигрировать у автора. Помнится, мы лет двенадцать назад переводили кучу проектов с Delphi 6 на Rad Studio 2007 и в общем-то оно заняло пару дней с минимумом правок. В том числе и плагины самой IDE («эксперты», как их там называли)

Зависит от кол-ва накопленного кода: своего и чужого.

Тоже доводилось лет 10 назад перетаскивать проект с Delphi 7 на актуальную тогда RAD Studio. Выездная сессия, команда из 10 человек, 2 недели. Проект был на 10 миллионов строк кода.

У меня нет столько грамотных людей, чтобы перетащили мои личные архивы.

А сколько там строк?

У меня 4 винта по 1Гб, но там не только коды, но по несколько ОС, и тексты статей и инструкций. + много DVD. Много дублируется. Многое сжато. Надо месяцами разбирать, что переносить. Я храню промежуточные версии. Для переноса надо чистить мусор и тестировать полученный перенос — это задача не одного года.

А системами контроля версий, типа git или mercurial не пробовали пользоваться? Я для себя mercurial открыл больше десяти лет назад, и все личные проекты долго в нем версионировал.

Я не знаю, что произойдет с ними через несколько лет. Одно время я писал и обсуждал в ру-блоге ISN. А потом они все потерли.

Локальный git/mercurial никто, кроме вас, не потрёт.

Сейчас — да. А что м.б. через несколько лет никто не знает. ИМХО история DEC очень поучительна.

А что может случиться через несколько лет с репозиторием, который представляет собой папку в вашей файловой системе, чего не может случиться с любой другой папкой в вашей файловой системе?

Зачем мне системама контроля версий? Проги с оригинальными алгоритмами храню с первой версии. Т.к. и она может оказаться нужной. Пройдет время и вылезет пропущенный баг. Возникнет вопрос на какой версии он был пропущен? М.б. в первой этого бага не было и он завелся в результате следующих изменений.

Так команда git bisect именно эту задачу автоматизирует.

Бывают случаи, когда человек правит код и его отвлекают — и он попал по клавише не в том месте — выражение изменилось — вместо плюса минус. Но последущие тесты и работы с прогой этого места не коснулись. В таком случае стоит глянуть правильно ли работает это место в первых версиях.
Как тут поможет git bisect?

Здесь вам даже git bisect не нужен. Вы просто делаете git checkout тэг-первой-версии и прогоняете свои тесты там. Вот если там всё работает, и если вы хотите найти место, где всё сломалось, то вы начинаете бисект, помечаете первую версию как хорошую, HEAD как плохую, и либо прогоняете логарифмическое от количества ревизий количество тестов, либо пишете скриптик, который запускает нужный тест и возвращает его статус, и git bisect находит вам плохой коммит сам.

А тут поможет банальный просмотр изменений перед коммитом, который, например, показывает sublime merge. Вы увидите во-первых, файлы, в которых произошли изменения, во-вторых, сможете хоть построчно эти изменения принять/откатить до того, как ваша работа уйдет в коммит.


Все cvs разных сортов автоматизируют утомительную ручную работу с find, diff, cp, patch и другими утилитами, которые можно использовать для того же самого, хранят историю, позволяют вести работу в нескольких ветках над одним и тем же кодом, обмениваться сделанной работой, и все это без облаков и сетевых служб.

Система контроля версий для этого отлично помогает, см. git bisect.


Я даже свои локальные проекты все храню в локальном гите просто потому, что это удобнее.

Зачем мне системама контроля версий?

Ровно для того, чтобы иметь доступ ко всем версиям и их истории, как и любому другому разработчику.


Проги с оригинальными алгоритмами храню с первой версии. Т.к. и она может оказаться нужной.

Вот как раз в этом случае СКВ прекрасно помогает: переключились на первую версию, увидели весь код, как был.


Возникнет вопрос на какой версии он был пропущен?

git bisect, как вам уже не раз написали.

Я так понимаю, вы путаете git (программу) и GitHub (облачный сервис).

Читаю в Вики:


Git — распределённая система управления версиями.

Репозиторий Git бывает локальный и удалённый.

Я и решил, что Вы мне облако советуете. А с версиями (локально) у меня обычно нет проблем, но мусор, если нужно предпочитаю разгребать руками.

Специальная программа для незаведения мусора типа my_program_YYYYMMDD_final_2_fixed_3.arj с этим справится ещё лучше ;) А если рабочих мест >1, мусора возникает ещё больше.

Рекомендую таки попробовать. Денег за это не берут, все что нужно - время от времени запускать tortoise hg и нажимать кнопку commit.

Спасибо,
попробую. Но в общем придерживаюсь принципа KISS («Keep it simple, stupid»). Если легко могу без чего-то обойтись, то режу бритвой Оккама.

C git/mercurial ничего не случится. Это системы контроля версий. Репозиторий хранится локально. От потери данных сам по себе не спасёт (нужны бекапы и т.п.), но от кучи дубликатов вполне может помочь

Когда я в последний раз интересовался этой темой, мне советовали поэтапно переводить через каждую следующую версию, этапов в 5. Надо попробовать ваш рецепт..

Помнится, мы лет двенадцать назад переводили кучу проектов с Delphi 6 на Rad Studio 2007 и в общем-то оно заняло пару дней с минимумом правок.

Переход с версии на версию Delphi/Rad studio достаточно прост, но может быть все-таки сильно осложнен двумя проблемами.

Первая и часто почти непреодолимая - сторонние компоненты, заточенные под определенную версию. Часто без исходных кодов и без развития с вариантами под новые версии среды разработки.

Вторая легко преодолима, но очень трудозатратная - строки. К счастью, проблема проявляется только один раз в жизни проекта. Был там момент перехода на уникод, для перехода через который приходилось очень много переделывать с этими самыми строками.

Остальное там достаточно просто решаемо.

А нет никаких проблем миграции, кроме строк ставших юникодными(WideString), впрочем возможность поменять string на AnsiString там, где Юникод не применим — есть. Есть примеры проектов на сотни тысяч строк кода, которые «мигрировали» на последнии версии Delphi за несколько дней.
Автору можно посоветовать: попробовать бесплатную Delphi Community Edition, новая версия которой вышла буквально вчера. Либо Lazarus, где UI по умолчанию очень привычен для пользователя Delphi 7, однако это современная IDE, с современным компилятором FreePascal и работающая везде, в том числе под Linux.

Это "современное" устаревает со страшной силой и супермодное уже через пару лет выглядит смешным. Паскаль как мертвый язык хотя бы не меняется.

Delphi меняется

FPC не спасет аксакалов?

Остаётся отдать должное стойкости людей, отказывающихся принять прогресс.

И я не про текущие технологии и реализации, а про то, как они будут искать тех, кто примет и продолжит.

Новое не всегда прогресс, к сожалению.

Вероятно, это особенность нервной системы. Кому-то больно использовать старые стандарты/компиляторы, а кто-то из версии в версию Boost тащит поддержку pre-C++11.
Боль наступает, если по недосмотру они попадают в 1 проект (я такого не встречал).
Подозреваю, что автор в своё время набрал кучу чужих библиотек без исходников, которые сейчас авторами заброшены и под новыми версиями Delphi не работают. Это единственная причина сидеть на старье.

Чужие библиотеки с исходниками, и даже купленные с исходниками - совершенно не гарантируют что они не будут заброшены авторами, и что вообще автора можно будет найти. И самостоятельно мигрировать чужую библиотеку на новую версию Delphi - тоже тот еще квест. На этом фоне радуют FastReport - многие годы никуда не деваются, а последняя версия все еще работает и на Delphi 7 и на Lazarus.

Тут возникает вопрос: а надо ли так держаться за язык, компиляторы которого несовместимы, а новые версии обратно-несовместимы?
Обратная совместимость в языке — одна из лучших. Однако некоторые авторы библиотек намертво привязывались к определенным недокументированным вещам, конкретному поведению конкретных версий библиотек, ОС, и т.д. — в целом как и везде в нативном мире.

А извините, у каких языков компиляторы полностью совместимы?

И полностью обратно совместимы?

Как-то решал в Gentoo квест - собрать старый компилятор еще более старым компилятором, чтобы собранный компилятор откомпилировал нужный код.

Если кратко - хоть и близко, но еще нет абсолютной обратной совместимости.

Плюсы не близки к этому ни де-юре, ни тем более де-факто. Поэтому, например, в одной компании, где я работал, миграция компилятора с GCC 4.2, кажется, на 4.7 заняла шесть лет (вместе с включением -std=c++0x), а 4.7 на 5.3 — ещё два года.

>с GCC 4.2, кажется, на 4.7
Это там бинарную совместимость сломали? Тогда совершенно неудивительно.

Там дело было не в бинарной совместимости (у компании был серьёзный NIH-синдром и все исходники доступны), а в том, что и компилятор, и стандарт стали чуть строже.


Аналогичные проблемы у меня были и в другой компании, где я пытался заставить код, написанный под gcc 6, собраться под gcc 9 и не помню каким clang, но там я в одно лицо управился всего за месяц, ибо кода там было всего-то 50-100 kloc.


Олсо, к слову о бинарной совместимости, её сломали и в C++17 (noexcept стал частью mangled-имени), и в C++20 (из-за концептов и известной темы с requires true).

Delphi 5, Delphi 6, Delphi 7 — полностью совместимы. Без проблем пеходил не меняя кода. Даже асм заплатки.

Я мигрировал так: Delphi 1->2->3->5->7.

Каждая миграция вызвана тем что в новой версии есть то чего мне в старой не хватает. Соответственно, раз в новой есть а в старой не было - полной совместимости нет. Остановился на D7 потому что этой версии мне достаточно и нет причин тратить ресурсы на более новую.

Каждая миграция не обходилась без проблем. И это при том что все компоненты с исходниками. Хорошо что написано много своих велосипедов - их мигрировать проще всего.

Сейчас использую все это под Win10. Есть некоторые шероховатости с юникодом, но в целом - все хорошо. Пример шероховатостей - системный символ рубля стал юникодным :) Т.к. мы работаем исключительно в рублях - просто везде убрал вывод денежной единицы. При желании можно было подменить на неюникодный, но смысла нету.

Прикупил TurboDelphi но так на нее и не перешел.

Delphi 8 это версия Delphi 7 но с компиляцией под .NET платформу, естественно там многое несовместимо стало, тот же тип variant был чисто формально, так как работал совершенно по другому.

И к смерти Delphi это не привело, только к банкротству Borland, но исходники были выкуплены другой студией и развиваются по сей день.


Однако следующие владельцы отказались от этой версии, и продолжили развитие исходников Delphi 7, и совместимость кода практически полностью сохранена, там разве что внутренности record превратили в object, а object в обрезанный class, который самоинициализировался, не требуя ручного создания и удаления. При переходе с Delphi 7 на Delphi 2006 ничего даже не приходилось переписывать, все работало сразу, отличия были только в некоторых ухищрениях, коими я пользовался исключительно для решения задач на саморазвитие вроде "можно ли обмануть компилятор", но такой код никогда и нельзя применять в серьезных проектах.

После Delphi 2010 ситуацию не знаю, помню на нем изменили базовую кодировку, а так как я уже не работал в той компании, где проекты писались на Delphi 2006, а они не планировали переход хотя бы на Delphi 2010, то мне пришлось отказаться от сопровождения одного проекта, даже за неплохие в то время деньги. (п.с. покупать более старую версию, или искать в инете крякнутую, ради возможности продолжать раз в год дополнять новыми шаблонами код, не имело смысла, а переписывать код под новую версию, мне сказали так не делать).

В то же время разработчики Delphi XE заверяли в свое время о полной совместимости старого кода вплоть до Delphi7 и мертвого Kylix, на практике не проверял.

Зато с Lazarus почти полная совместимость кода, даже до сих пор есть режим Delphi 7, который как раз должен помочь безболезненно перенести весь код без изменения (ну разве что в начале модуля добавить надо будет директивы компилятора, которые будут указывать на код D7). Или есть встроенный инструмент преобразования кода Delphi на Lazarus, правда насколько хорошо он работает я не знаю, никогда им не пользовался.


Но и без этих как по мне костылей, как уже было написано выше 90% кода (а то и больше) будет работать без изменения, а небольшая разница легко заменяется аналогами, если не требуется какой-то специфики, выходящей за рамки стандартов (и тут идет речь о самом синтаксисе ЯП и некоторыми классами для оконных компонентов, а не алгоритмов каких-то вычислений).

Один только нюанс, в какой-то момент сообщество Lazarus по умолчанию String прировняли к UTF8String (что вполне логично, так как это давно стало стандартом почти для всех современных ЯП), потому для полной совместимости, если использовались манипуляции с текстом вроде подмены символов, для совместимости необходимо было указать вместо string тип AnsiString.
Что занимает несколько минут работы, учитывая что в среде есть поиск по проекту с автозаметой.

Тут возникает вопрос: а надо ли так держаться за язык, компиляторы которого несовместимы, а новые версии обратно-несовместимы?


python2/3, C++, ну их всех, ага ;)

Если оно чинится в полуавтоматическом режиме, а все несовместимости вываливаются на этапе компиляции, то вполне можно держаться.

Попробуйте python 3 + typing модуль. Код будет не хуже.

Интерпретатор вместо нэйтива для научных числодробилок? Серьезно?

"Дробить"-то все равно будет numpy или что-то похожее. Возможно, даже через CUDA или OpenCL.

Нафига нужен питон, если всю работу за него делают языки, на которых написаны библиотеки и расширения?

Чтобы вызывать эти библиотеки и расширения было проще.

Потому что код на питоне — это способ по-быстрому связать разные либы в одном пайплайне. Как трубопровод в шелле.
Для остального он слишком тормозной.

Мы тоже несколько месяцев назад так подумали и решили вместо Python-версии Tensorflow использовать С++-версию (на кой нам лишние обёртки?). Потребление памяти снизилось заметно, время работы — на жалкие проценты в пределах погрешности. Зато код распух в десятки раз.
В итоге плюнули и вернулись обратно на Python.

Попробуйте впихнуть в значимое имя фразу: загрузить из архивного файла, записи для товарных вагонов, расшифровать их, пустые вагоны добавить в таблицу свободных вагонов.

Так даже впихивать не надо.

Тут явно напрашивается разбить это все на функции, которые можно назвать одним-двумя-тремя словами.

Тогда код будет чуточку более самодокументируемым и чуть менее нуждающимся в комментариях :)

Разбить на ф-ции проще простого. И код будет имнть кучу повторяющихся фрагментов:


загрузитьИзАрхивногоФайла(записиДляТоварныхВагонов);
расшифровать;
пустыеВагоныДобавить (таблицаСвободныхВагонов);

Если фрагмент повторяется многократно, то его обычно прячут в ф-цию. Получим:

загрузитьИзАрхивногоФайлаРасшифроватьПустыеВагоныДобавить(записиДляТоварныхВагонов, таблицаСвободныхВагонов);

Будем честными, оба варианта выглядят странно, потому что не очень понятно, где же чья ответственность. У вас правда одна функция возвращает два слабо связанных набора данных (товарные вагоны и свободные вагоны)?

Так давно никто не делает. Всё это решает ооп, где всё сильно упрощается [впрочем, и усложняется тоже].

Если ооп, то у вас всё это разлетится на кучу объектов, где совершенно не будет монструозных длинных имён.

Объект Файл, у него функция Файл.Загрузить();

Абстрактные объекты записей будут, от них наследованы ваши записи.

У вас там выше не товарные вагоны должны добавляться, а записи.

СписокЗаписей.Добавить(Запись); А то что под записью это запись товарного вагона - за это и отвечает ооп. И не важно что у вас там - товарные вагоны или не товарные, буратины или боенги с кирпичами, ооп разгребёт всё само, на то оно и ооп.

И т.д. и т.п.

Если фрагмент повторяется многократно - то зовут вменяемого программиста, который накорячит архитектуру под определённый язык и сообразит библиотеку базовых типов под это всё дело, а так же основные базовые действия с типами, их преобразования и т.д. Обычно оно называется фреймворком.

Не использование ооп там где это действительно может помочь - глупейшая ошибка. Впрочем, использование ооп там где оно нафиг не нужно и можно обойтись без ооп - ещё более глупая ошибка.

Однако же т.к. автор - учоный [вроде бы], то и спрашивать с него нечего. Понять, простить.

Разбить на функции проще простого можно тогда и только тогда, когда нет абстракций. А у учоных их нет) Учоный мир живёт на композициях, потому то оно и не интересно.

Специально для учоного:

Понимание - это сравнение. Но механизмов сравнения абстракций у учоного мира не существует. Отсюда все беды. И эти беды у программистов отсутствуют.

Как обычно пример на пальцах. У меня знакомый физик есть, и он упоротый как любой учоный. Я ему так и смог объяснить что Солнце - это не звезда, а имя собственное. Вот хоть тресни - не получается. А ведь человек публикуется в очень крутых местах. А уж собрать базовую систему типов астрономических объектов для учоного - это вообще нерешаемая задачька по определению.

Причём понятное дело что Солнце как имя собственное должно быть приляпано как интерфейс к абстракции астрономического объекта, смех в том что в этот интерфейс ещё и абстракции народности надо забрасывать, ибо всё у всех называется по-разному.

И т.д. и т.п.

Я высупал в защиту ООП. И исполюзую ООП. Но при разработке нового алгоритма ООП не всегда удобно. И для описания м.б. не очень удобно.
И да, я "учоный", но многие мои проги к науке отношения не имеют.

Зачем тут вообще ООП, когда это решается системой модулей?


import MyFavouriteFileLib.Data.File as File

-- ...

foo = File.load "filepath"

Ух, правы были некоторые фанаты окамля, когда говорили, что в подавляющем большинстве случаев ООП ­— это такие модули для тех, у кого в языке адекватную систему модулей не завезли.

"Зачем тут вообще ООП"

"в подавляющем большинстве случаев ООП ­— это такие модули"

"X as File"

Гонг вопрос: где тут ооп, а где тут нет ооп?

Всё смешалось... Кони... Люди... (с) кто-то

И объекты в окамле малопопулярны, похоже, потому что львиная доля случаев их применения покрывается старыми добрыми (в ML) модулями.

Повторяющиеся вызовы функций все же несколько лучше повторяющегося кода их реализации, сопровождающегося комментарием.

Чем лучше?

Например, если в реализации найдётся ошибка, то её достаточно исправить в одном месте.

Да, это так. И я это имел в виду, когда сказал про повторы фрагментов. Но речь шла об огромных именах для замены комментов.

При грамотной декомпозиции, огромные имена просто не понадобятся

Ну и как впихнуть в значимое имя фразу: загрузить из архивного файла, записи для товарных вагонов, расшифровать их, пустые вагоны добавить в таблицу свободных вагонов? Так чтобы было понятно какие действия совершает прога.

свободныеВагоны.добавитьИзАрхивногоФайла(...)


Какая разница, расшифровывает оно их или нет?

Очень большая. С шифрованными записями прога не сможет работать.

Это значит, что при чтении вы их всегда расшифровываете, и именно поэтому совершенно нет необходимости это указывать в названии операции.

Не значит. Нпр., для ускорения поиска по БД поле "тип записи" можно не шифровать. Если тип записи = "ТВ", то это запись товарного вагона.

Но у вас не операция поиска, у вас операция загрузки свободных, а ее нельзя сделать без расшифровки. Пойнт в том, что для получателя, которому нужен список свободных вагонов, пофиг, пришлось вам их расшифровывать, или нет. Какая разница?

Есть: загрузить из архивного файла, записи для товарных вагонов. Это может значить найти и загрузить.


Пойнт в том, что для получателя, которому нужен список свободных вагонов, пофиг, пришлось вам их расшифровывать, или нет.

Согласен, что конечному юзеру пофиг. А программисту который пришел на место разраба очень важно понять, почему в методе добавитьИзАрхивногоФайла после чтения идет много строк кода. Напомню, эта ветка обсуждения началась с идеи отказа от комментов, и замены их именами.

А программисту который пришел на место разраба очень важно понять, почему в методе добавитьИзАрхивногоФайла после чтения идет много строк кода.


Много строк кода вынесены в функцию DecryptDataFromDB, например. Программист понимает, что это что-то связанное с расшифровкой.

Программисты — они понятливые, но вместо того, чтобы в одной строке коммента прочесть, программисту нужно бегать по разным функциям. Что быстрее? эргономичнее?

Нет, не надо ему никуда бегать.


Покажите уже пример, а то мне кажется, мы друг друга не понимаем.

Я показал:


//загрузить из архивного файла, записи для 
//товарных вагонов, расшифровать их, пустые 
//вагоны добавить в таблицу свободных вагонов

Непонятно. Где этот комментарий написан-то? Как он с кодом соотносится?

Cоотносится, как и всякий комментарий. Нпр.:


begin
loadFile;
//загрузить из архивного файла, записи для 
//товарных вагонов, расшифровать их, пустые 
//вагоны добавить в таблицу свободных вагонов
nextProc;
end;

Все равно не понимаю. Где выполняются все перечисленные действия?

В процедуре loadFile; просто формат Хабра не позволяет разместить этот вызов и следующий комментарий в одну строку. На практике такой проблемы нет.

Т.е. этот комментарий видит тот, кто вызывает процедуру, а не тот, кто ее правит. Тогда:


  1. его придется повторять (и поддерживать актуальным) везде, где процедура вызывается
  2. он содержит ненужную информацию (выше уже обсудили, что вызывающему нужно только знать, что и куда будет добавлено)
  3. не решает озвученную вами же проблему с "программист, который пришел править loadFile не понимает, зачем там столько кода", потому что вот как раз этому программисту этот комментарий не виден

Решение вида


data = Data.read()
data.freight //товарные
data.free //пустые

лишено всех описанных проблем, и комментарии в нем только для целей демонстрации сейчас, в коде они нужны не будут.

Можно записать коммент в определение процедуры loadFile:


procedure loadFile;
//загрузить из архивного файла, записи для 
//товарных вагонов, расшифровать их, пустые 
//вагоны добавить в таблицу свободных вагонов
begin

В Вашем решении не понял: что делают методы freight и free?

Можно записать коммент в определение процедуры loadFile:

Тогда возникает следующий вопрос: а почему бы их просто не заменить понятным кодом:


procedure loadFile;
begin
  loadFromArchive;
  decrypt;
  //и так далее
end

Для кого эти комментарии?


В Вашем решении не понял: что делают методы freight и free?

Это не методы, это свойства (или атрибуты структуры). Возвращают загруженные, соответственно, все товарные вагоны и свободные вагоны. Если все товарные вагоны не нужны, а нужны только пустые, можно упростить до:


data = Data.readFreeCars()

Если две строки рядом: одна за другой, то читать легко. А если:


procedure loadFile;
var
 err : integer;
begin
 err:= loadFromArchive;
if err<0 then
begin
 if err=-1 then
  print ('I/O error')
else
 if err=-2 then
 print ('File not found')
else
 print ('Unknown error');
exit
end;
decrypt;
  //и так далее
end

Применительно к этому куску кода.. exception'ов разве в Delphi не завозили?

Завозили, но речь не о том. Речь про отказ от комментов и про использование только значимых имен. Чем больше строк между такими именами — тем труднее читать, тем привлекательней комменты.

Неа, комменты все еще не привлекательны, потому что они требуют дополнительного труда по поддержанию, и все еще не отвечают на вопрос "что происходит в этом месте кода".

Ну ИМХО это уже философский вопрос: насколько реальность отвечает нашим ожиданиям, Статья про разработку новых алгоритмов, и, в этом случае, комменты особо важны: читаем, что хотел автор, и смотрим код: что у него получилось.

Статья про разработку новых алгоритмов, и, в этом случае, комменты особо важны: читаем, что хотел автор, и смотрим код: что у него получилось.

Вот именно поэтому комменты надо писать там, где алгоритм, который нетривиальный, и не надо писать там, где инфраструктура.


В вашем примере, который про загрузку файлов, как видим, комментарии избыточны.

decrypt м.б. нетривиальный по новому алгоритму и
loadFromArchive может быть новым. Может новый драйвер на асм.

В данном примере это не так. Если же алгоритм новый, то комментарии должны сопровождать код, а не быть от него отделены.

Ok. Договорились, что комментарии нужны (в разумных объемах).

… то тоже легко, более того, хорошо видно, когда-таки началось дешифрование. Особенно если не забывать пустые строки вставлять.


А еще можно обработку ошибок переделать, и оно обратно схлопнется.

Пустые строки сродни комментам?


Кроме обработки ошибок, потом может новый код добавиться.

Пустые строки сродни комментам?

Нет, пустые строки сродни разделению текста на абзацы.


Кроме обработки ошибок, потом может новый код добавиться.

… а вы в этом случае комментарий сверху тоже обновите?

Вот это и есть та самая лишняя работа. Намного выгоднее вынести этот лишний код в отдельную процедуру, сохраним читабельность.

И чтобы узнать, что делает этот код нужно лезть в отдельную процедуру.

И чтобы узнать, что делает этот код нужно лезть в отдельную процедуру.

Нет, достаточно прочитать название процедуры.

LoadFileEx ;)

Нет. Уже обсуждали, что для пользователя важно только то, что она загружает данные, поэтому loadData.

Не понял: пользователю доступен исх.код?

Пользователь процедуры — тот программист, который ее вызывает. Тот, для кого вы комментарии пишете. Поэтому да, доступен.

В таком случае, возможно, он напишет:


loadFile;
decrypt;


при достаточной области видимости decrypt результат будет плачевным.

при достаточной области видимости decrypt результат будет плачевным.

Это та причина, почему область видимости должна быть минимальной.


А еще это та причина, почему decrypt не должен работать с общим состоянием, тогда ничего плачевного произойти не сможет по определению.

Желаемое vs действительное...

Не очень понятно, что вам мешает писать код так, чтобы он соответствовал вашим желаниям.

Я про Ваши желания:
"область видимости должна быть минимальной",
"decrypt не должен работать с общим состоянием".

И я про то же самое. Что вам мешает сделать decrypt с минимальной видимостью и не давать ему работать с общим состоянием?

В общем случае decrypt должен работать не только с loadFromArchive. М.б. в последующих версиях.

В таком случае, эта процедура будет доступна вызывающему программисту безотносительно того, сделали вы комментарии или нет. Защищайтесь типами, и будет вам благо.

Это как защищаться, чтобы без комментов?

Давайте начнем с простого вопроса: а как вам комменты помогуть защититься?


А так-то, защищаться очень просто: если decrypt принимает только byte[], а возвращает Car[], и при этом loadData возвращает Car[], программисту неоткуда будет взять byte[], чтобы их передать в decrypt.

Неубедительно. Если decrypt могут вызывать другие процедуры, то decrypt должен работать с их данными. А иначе — абсурд.


а как вам комменты помогуть защититься?

Коммент с описанием loadFile после заголовка сообщит, что тут decrypt уже использован.

Неубедительно. Если decrypt могут вызывать другие процедуры, то decrypt должен работать с их данными.

Тем не менее, вход и выход у decrypt всегда отличаются (или можно сделать так, чтобы отличались), потому что зашифрованные и расшифрованные данные — это разное. Это прекрасный способ защититься от случайного дешифрования чего угодно.

Вход и выход типа string, иначе какой смысл делать decrypt видимым?

Вход и выход типа string, иначе какой смысл делать decrypt видимым?

Прямой. Есть куча полезных сигнатур decrypt, начиная с T decrypt<T>(Encrypted<T>), через T decrypt<T>(Encrypted) и заканчивая string decrypt(Encrypted) и string decrypt(byte[]). Было бы желание сделать код безопасным — будет и решение.


Вы так и не ответили, а комментарий-то вас как защитит?

Это никак не помешает программисту вызвать decrypt самому. Комментарии читают не всегда. А разумные типы и узкие области видимости — помешают, просто не скомпилируется.


Или вот тоже: у вас A вызывает B, B вызывает C, а C вызывает decrypt — вы на всей цепочке вызовов будете писать "вызывает decrypt"?

Комментарии читают не всегда.

Это проблема тех, кто не читает.


вы на всей цепочке вызовов будете писать "вызывает decrypt"?

Не надо доводить до абсурда. Серебряной пули нет.

Это проблема тех, кто не читает.

Тогда и то, что программа ломается, когда кто-то вызывает decrypt после load — тоже проблема того, кто вызывает. Симметрично.


Не надо доводить до абсурда. Серебряной пули нет.

Серебряной пули нет, но есть более и менее надежные способы. Типы и сокращение видимости — более надежно, чем комментарии.

В процедуре loadFile


Я лично не люблю, когда функция loadFile, кроме загрузки файла, делает ещё какие-то не сильно очевидные действия (варит кофе/форматирует диск Ц/взрывает Звезду Смерти). Например, во всяких инспекторах классов имена функций видно, а комментарии — нет. Нужно помнить что Class_a.loadFile — просто загружает файл, а Class_b.loadFile — загружает файл и варит кофе.
Но у каждого свои предпочтения.

Если ТЗ требует формат после удачной загрузки файла, то желание заказчика — закон исполнителю. И кофе можно сварить: хозяин — барин ;)

Что быстрее? эргономичнее?


Отдельная функция, конечно ;)
При просмотре кода — если нет необходимости смотреть на код расшифровки — туда просто не смотрят. Если есть необходимость — переход в функцию это 1 щелчок мыши, в чем проблема?
При отладке — просто не заходим в функцию, это быстрее, чем пролистывать на 200 строк вперед.
Но я не настаиваю ;)
Есть: загрузить из архивного файла, записи для товарных вагонов. Это может значить найти и загрузить.

Потребителю это все равно не важно.


Согласен, что конечному юзеру пофиг.

Ну так дескриптивное имя операции — он для конечного юзера (операции) делается.


А программисту который пришел на место разраба очень важно понять, почему в методе добавитьИзАрхивногоФайла после чтения идет много строк кода.

А для этого программиста эти "много строк кода" выносятся в метод с понятным названием decrypt, и у него тоже вопросы пропадают. Так оно и работает.

Абсолютно также подумал когда читал.
Классический рефакторинг ExtractMethod.

Делаем примерно следующее:
BoxcarsData = LoadBoxcarsFromArchive();
Boxcars = ParseBoxcarData(BoxcarData);
FreeBoxcars = GetFreeBoxcars(Boxcars);
UpdateFreeBoxcarsList(FreeBoxcars);

Чепуха какая то. В delphi 7 юникод есть. Современные языки это неповоротливые великаны. Попробовал недавно поучится rust. Современный. Так оказывается, чтобы скомпилировать, ему нужно весь microsoft visual c++. И ещё кучу прибабахов. Код получается ну очень огромным.

Что-то вы недоучили. "Hello World" под Линукс весит 151 байт, под винду 1500 байт. Но конечно, если собирать в дебаг-режиме, с настройками по умолчанию, которые пихают вообще всё, что можно, в бинарь...

Ну у меня так получалось. Да и плюнул я на это, не стал учится.

Которое весит мегобайт 900. И хрен поймёш как настроить потом всё это.

Ну да, весит много. Но у вас разве нет свободного гига для нужд разработки?

Плюс, ничего больше настраивать не надо.

Ну так-то да, clang 12 под win почти 2 гб установленный занимает. и это с учетом что там нет STL еще, которая есть в MSVC.

Пакет conan который я делал где чисто под 1 платформу компилятор и хидеры, для последней версии 300 мб в распаковке на диске.

Но компилятора мало, скорее всего еще Windows SDK нужен.
Опять же под одну платформу (х64) все необходимые файлы в распаковке примерно 500 Мб.

Ну и сравнить например с IDE Qt Creator — где нет ничего (ни компилятора, ни дебаггера, ничего, просто редактор со всеми ништяками) — 600 Мб на диске.

Не выглядит как что-то на что стоит жаловаться. я бы только на clang жаловался, какого он жирный такой)

p.s. ну а настройка это да, это смех — установил компилятор и все, популярные ide подхватят все сами. для консольки — vsvarsall.bat дернул, шо еще надо-то…

Да не хочу я больше это изучать. Вот C/C++ другое дело. mingw скачал и установил. Больше никаких манипуляций. Если конечно не понадобится что то вроде qt.

Ну хорошо, хорошо! Так и запишем - не осилил установку компилятора.

Так ведь у Rust аж на 1 манипуляцию больше, чем у C/C++:
  • Устанавливаем C++ build tools от Microsoft или MinGW
  • Запускаем rustup, который установит Rust

По умолчанию почему-то ставится msvc-версия. Если насильно ткнуть при установке в gnu-версию, то не надо ничего, рядом сам ставится mingw.

Если насильно ткнуть при установке в gnu-версию, то не надо ничего, рядом сам ставится mingw.

Думаю, человек был недоволен зависимостью от компилятора другого языка, а не тем, что нужно зависимости руками доставлять.

Надо попробовать. Не знал.

Он может использовать и gcc. Не обязательно visual c++.

Только бинарники будут в 10 раз больше, и некоторые зависимости под чистую винду не будут находиться.

Насколько помню, в Delphi, чтобы избавиться от проблем с кодировками, достаточно у визуальных компонентов в "пропертях" явно задать кодовую таблицу RUSSIAN (или CYRILLIC, не помню) вместо DEFAULT. Плюс для корректной работы старых программ, которые нет возможности или желания перекомпилировать, подкорректировать раздел FontSubstitutes в реестре, типа вот так:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontMapper]
"ARIAL"=dword:000000cc
"DEFAULT"=dword:000000cc

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]
"Arial,0"="Arial,204"
"Courier New,0"="Courier New,204"
"Microsoft Sans Serif,0"="Microsoft Sans Serif,204"
"Tahoma,0"="Tahoma,204"
"Times New Roman,0"="Times New Roman,204"
"Trebuchet MS,0"="Trebuchet MS,204"
"Verdana,0"="Verdana,204"

ну и, если необходимо, добавить в этот список какие-то другие используемые шрифты.

Я просто нашел в сетке свободную б-ку стандартных компонентов в юникоде и переименовал каждый компонент в файле проекта с их списком.

Почему я продолжаю использовать устаревшие виртовский Pascal и Delphi-7

Тут только один ответ, вам лень выучить что то новое. А поводов оправдаться, ну вон целая статья найдется

Почему лень. Я упоминал OpenCV, CUDA — учил самые свежие версии. Очень много времени у меня уходит на графы — много читаю интересных статей. Ну, и на химию.

Ну вот и ответ, нельзя быть хорошим химиком и программистом, точнее можно, но очень сложно.

И тут явно видно что вы не справляетесь, так как пишите на мёртвом языке, который сейчас слабо востребован на рынке.

На всякий случай, слабо, это не значит совсем, вы же как то нашли работу.

Не обижайтесь пожалуйста, если комментарий вас задел, просто снял вам розовые очки.

Все эти компоненты vcl были хороши для своего времени. Но сейчас на первое место выходит поддерживаемость, поддержка многопоточности, асинхронности из коробки, и всякого синт сахара типа async await.

То что вы можете быстро накидать комп на форму и запустить апп на винде это хорошо, но сейчас все ушло в веб, и я сейчас не только о фронте.

Бэк энд тоже сейчас чаще дёргается по grpc или rest

А хорошим химиком и физиком можно быть? Много людей работают в физхимии, в Москве 2 НИИ РАН: физхимии и химфизики. Получается работать на стыке наук. Почему Вы думаете, что невозможно работать на стыке химии и CS?
Это Вы не обижайтесь: Вы в розовых очках полагаете, что использование новейших технологий делает Вас хорошим программистом.

И тут явно видно что вы не справляетесь

Не видно ;) Статья как раз о том, что справляется со своими задачами с помощью устаревшего языка.

Версия языка Delphi обновляется каждый квартал. Delphi давно не привязан к одной платформе (Windows) и позволяет писать и на Linux/Android/iOS/MacOS/Windows один кроссплатформенный код. Давно умеет в быструю и простую асинхронность (TThread/TTask/TTaskPool) (куда лучше чем async/await, например в шарпе).

Дизайнер окон мощнее любого из существующих (погуглите на эту тему, если есть сомнения).

Помимо всего этого, погуглите Delphi TMS Web, Delphi uniGUI.

Давно умеет в быструю и простую асинхронность (TThread/TTask/TTaskPool) (куда лучше чем async/await, например в шарпе)

Простите, а как вы это сравнили? Потому что таск-пул — это совсем не то же самое, что async-await.

Я знаю что async/await в C# - это не про прямую многопоточность. В этом и суть. Эффективнее использовать как раз таски.

"Эффективнее" для чего?

Если не использовать родной VCL и прямо указывать тип строк то проблем с уникодом у D7 нет.

Дошёл до абзаца про математически строгие доказательства, уж было напрягся, но так и не понял, как вы это решаете на паскале.

На псевдокоде. Нпр., если в алгоритме 2 цикла (1 вложен), и делают m и n шагов, то в наихудшем случае алгоритм сделает mn шагов.

если в алгоритме 2 цикла (1 вложен), и делают m и n шагов, то в наихудшем случае алгоритм сделает mn шагов.

По разному бывает. Например, перевоплощение массива в бинарную кучу выглядит как O(n*ln(n)) - каждый элемент надо "просеивать", что вроде как ln(n). А по факту выходит O(n) на всё про всё.

Согласен. К этому подходу много критики. Так А.А.Зыков критикует в начале книги Тория графов.

Этак вы только сложность алгоритмов оцените сверху, но не их корректность.

Верно. Но если у нас граф с n вершинами и "координаты" текущей вершины (i,j) меняют два цикла от 1 до n, то можно сделать вывод, что в матрице смежности каждый элемент будет просмотрен 2 раза.

Как из этого следует, что ваш алгоритм даст правильный ответ?

Из этого следует, что подзадача просмотра м-цы смедности решается корректно. Аналогично для других подзадач.

volatile int sink = 0;
for (int i = 0; i < n; ++i)
  for (int j = 0; j < m; ++j)
    sink = arr[i][j];

Это правильная часть алгоритма?

Переведу на Pascal:


var  sink :integer;
begin
  for i:=1 to n do
    for j:=1 to m do
      sink := arr [i,j];
end;

Если правильно перевел, то правильная.

Но ведь он функционально эквивалентен алгоритму sink = arr[n, m], который проходит вообще только по одному элементу из всех. В чём его правильность?

Согласен. Поэтому правильнее написать так:


var  sink :integer;
begin
  for i:=1 to n do
    for j:=1 to m do
      begin
          sink := arr [i,j];
          proc (sink);
      end;
end;

Что значит правильнее? Вы же согласились, что предыдущий вариант тоже правильный. Куда уж правильнее?


Вот я написал ваш алгоритм на графах, который возвращает последнее значение в матрице смежности (или вообще 42). Сложность — O(1). Почему бы вам не заменить вашу реализацию на мою?

Ваш алгоритм м.б. удобен для отладки: смотрите под отладчиком значения sink на каждом шаге внутреннего цикла.

У меня почему-то никак сегодня не получается доносить свои мысли, так что забейте, все алгоритмы правильные.

Ok. Ваш м.б. назван Алгоритм проверки м-цы.

Согласен с автором.

FreePascal у меня, конечно, есть, но не пользуюсь. EmbarcaderoSydney тоже живёт в виртуалке. Для прототипов предпочитаю delphi7; живёт в виртуалке windows7 и проблем с юникодом не наблюдается. Получаются быстрые и надёжные прототипы, хоть в многопотоках, хоть в процессах, линкуется с чем угодно в себя и из себя.

Зачем учить пытон(тем более конкретно третий) сегодня, если завтра его сменит крокодил ?

P.S. Паскалем не ограничен = использую языковые инструменты в зависимости от задачи.

Вот тут бы пригодился транслятор из Паскаля в Python pas2py

Delphi-7 напоминает мне Windows XP. Устарел, но работает. И иногда проще ничего не трогать, если он выполяет все цели, для которых используется.

У меня, кстати, она стоит на компьютере. Я для каких-нибудь быстрых поделок её держу. Меня восхищает то, что она работает мгновенно. В смысле, вообще мгновенно — ты только нажал на сборку, а софтина уже собралась и запустилась.

Спасибо за замечание. Добавлю в статью. Я уже подзабыл "прелесть" медленных компиляторов.

Современный язык с реплом даст вам те же ощущения, только ещё с современными ништяками (которые, конечно, для разных людей разные важны).

Современный язык с реплом даст вам те же ощущения,

Я не знаю про существование современных языков с реплом, которые несколько сотен тысяч строк компилируют за доли секунды, но даже если бы были, для тех же ощущений мне понадобится ещё и IDE, где я могу мышкой нарисовать UI, причем с живыми данными в дизайнтайме.

Для своего времени Delphi-7 был реально очень хорош, на самом деле.

Такое ощущение, что вы пытаетесь оправдать свою лень освоить какой-либо другой ЯП. Текст полон стереотипов. Вот это например:

Pascal-образный (Pascal-like) псевдокод интуитивно понятен (всем кто знаком, хотя с одним универсальным ЯП)

конечно же, не использовать пресловутый goto

Да, именно лень является здесь основным мотивом:

Понятно, что возьму эти процедуры из своего старого кода. Но почему Delphi-7, а не более новое? — К сожалению, проблемы несовместимости.

Неясно только, почему бы в таком случае не сказать прямо - меня всё устраивает и переходить на что-то другое необходимости я не вижу.

Про лень уже отвечал. У меня много других дел. Про графы и химию читать...

Тогда почему написали не "у меня нет времени", а "интуитивно понятен", "goto" и другие отмазки?

Да, чувак реально странен. Я ему выше написал что есть люди которые 100 процентов времени тратят на айти и выдают гораздо лучший результат на новых языках, а он все по химию какую то.

Кстати по компиляцию о которой здесь много говорили, сейчас VS и. Net языки поддерживают hot reload. Тоже самое и для Java script фреймворков, типа ангуляра, в итоге я приложение иногда заново по несколько дней не компилирию, а изменения применяются мгновенно. Но автору поста это невдомек, у него химия и минусики поставить на комменты)

Мне плевать, как меня называют. Но дам совет, который м.б. поможет улучшить Вашу карму: я Вам, любезнейший, не "чувак". Выбирайте выражения — не в подворотне находитесь.

У Delphi есть огромное преимущество перед современными языками программирования (за исключением разве только C#): это полный комплект, всё в одном. Установив Delphi, вы получаете весь инстурментарий, а также полностью интегрированный с ним редактор, отладчик, визуальный редактор, библиотеку компонентов и справочную систему. Причём качество справки таково, что для подавляющего большинства современных ЯП попросту недосягаемо.
Соответственно, сразу после установки оно готово к работе. Вы можете тут же, буквально нажатием одной клавиши, собирать и запускать программу. Никаких прописываний путей и прочей настройки — это цельный продукт, а не паззл, который надо сперва собрать из кусочков. Точно так же вы можете сразу отлаживать, расставляя точки останова в редакторе. И никогда не будет проблем из-за того, что убогий gdb опять как-то не подцепился редактором кода или чего-то не нашёл. Вы сразу можете вызвать справку кликом по любому идентификатору, и для этого ничего не потребуется настраивать.
По сравнению с этим, инфраструктура современных ЯП кажется до ужаса убогой и неудобной. Это конструктор «собери сам», причём даже после сборки такого удобства как в Delphi не будет — вечно хоть что-то да отвалится.

Да, всё )))правильно: раньше не знали, что программировать надо весело и куульно. И ещё плюс, как заметили выше, скорость сборки. Но есть )))нюанс. Это до середины нулевых у российского программиста стояло разнообразное ''современное'' ПО для любой области интересов. Потом пришли лицензии и началось... Например, embarcadero вовсе не плохой продукт, но посмотрите на его цену или цену других профессиональных инструментов. Поэтому везде и широко бесплатный пытон для учёбы и прототипов.

Согласен. Но заказчики не хотят delphi. Хотят C++, С#, Python, Haskel. Если хочеш зарабатывать, а не философствовать, придётся использовать эти языки. Раньше можно было пол деревянными досками накрывать, и было хорошо. Теперь ни кто деревянные полы не хочет, хотят ламинат. Не скажеш же заказчику, давайте я вам лучше из сосновых досок пол сделаю.

Тут скорее вместо отработанной технологии строительства кирпичного дома заказчик хочет каркасник, потому как он быстрее и дешевле, да и вообще современнее.
Вот только если состояние кирпичного дома оценить довольно легко, то чтобы оценить состояние каркасника потребуется весьма дорогостоящая экспертиза. Дом может выглядеть идеально, но на самом деле там все балки давно сгнили и вся конструкция вот-вот сложится…

Заказчик хочет ламинат. Ламинат - это инструмент? Нет, это результат работы. Заказчику не важно, каким инструментом ты будешь укладывать ламинат. Главное, чтоб он был уложен и уложен хорошо.

Вот оказывается не всё равно. Посмотрите заказы на фрилансе. Везде требования к языку, и даже к среде разработки.

Если делать студентикам задачки, то конечно они просят на конкретный язык. А если найти на фрилансе нормальный заказ на создание той или иной программы, то только единицы могут указать конкретную технологию. И то, в таком случае достаточно поинтересоваться "почему?" и можешь сам предложить технологию. заказчику будет не важно.

Реч идёт вовсе не о студентиках. Ну, хорошо, посмотрите вакансии. Где там требуется программист со знанием Dephi 7?

При чем тут Delphi7? Современная среда разработки для Delphi - это RAD Studio 10.4.X, среда вышедшая в этом году.

И нет смысла спорить о вакансиях. Их мало, но они есть. С хорошей зп.

Но это же такое, одноразовое преимущество. Среду вы в любом случае настроили один раз, а потом существенно, асимптотически больше времени тратите на работу в ней. Поэтому лично меня не очень волнует, сколько времени я потрачу на начальную настройку, если потом моя производительность как программиста это время с лихвой компенсирует.

А потом вы захотите поставить эту среду себе ещё и на ноут, и там придётся настраивать заново, тратя кучу времени, чтобы всё работало вот как на десктопе, потому что к тому времени вы уже забудете, где и что ставили и как всё это сопрягали.
Мало того, весь этот инструментарий слишком сильно «зацеплен» за конкретную систему и потому очень хрупок. Перейдя допустим с Ubuntu на что-то ещё вы тоже потеряете все настройки и будете лепить всё заново.
Вот я, к примеру, из-за этого на Ubuntu 16.04 сидел до упора, пропустив 18.04, потому что был уверен, что при переходе всё сломается и надо будет настраивать заново. И да — когда на этом старье стало уже совершенно невозможно сидеть и пришлось переползать на 20.04, оно таки сломалось, и пришлось заново возиться с настройкой.
Причём каждый раз настройка — это не «вот потратил два вечера и дальше радуйся». О нет, потом в процессе работы то и дело натыкаешься на разные проблемы и шероховатости ещё не одну неделю. Всё время где-то что-то вылезает, и комфортность работы так себе, пока окончательно не отшлифуешь.
А потом вы захотите поставить эту среду себе ещё и на ноут, и там придётся настраивать заново, тратя кучу времени, чтобы всё работало вот как на десктопе, потому что к тому времени вы уже забудете, где и что ставили и как всё это сопрягали.

Не придётся, у меня все настройки в гите. Достаточно склонировать репозиторий с моего гитхаба и запустить скрипт, который раскидает симлинки как надо.


Мало того, весь этот инструментарий слишком сильно «зацеплен» за конкретную систему и потому очень хрупок. Перейдя допустим с Ubuntu на что-то ещё вы тоже потеряете все настройки и будете лепить всё заново.

У меня вообще дистрибутив с роллинг-релизом, и почему-то ничего не отваливается.

Разработка в Delphi достаточно быстра. Библиотеки для питона, которыми он так "славится" кто-то пишет. Т.е. такую же работу можно проделать и для Delphi. Т.е. опустим аргумент что "на питоне библиотеки для всего".

Далее, процесс разработки на Delphi не уступает питону. За исключением только что нужно освобождать память вручную.

Т.е. такую же работу можно проделать и для Delphi.

Только её надо проделать.


Т.е. опустим аргумент что "на питоне библиотеки для всего".

А вы этот аргумент будете для любого языка опускать, который поддерживает библиотеки?


Далее, процесс разработки на Delphi не уступает питону.

Почему вы вообще сравниваете с питоном? Я считаю питон ужасным языком для разработки, и для меня это утверждение не то чтобы сильно в пользу дельфи.

Сравниваю с ним из-за коммента выше и по причине его бессмысленной популярности, из-за которой его пихают уже просто всюду, где он даже на минималках не вывозит.

У делфи масса преимуществ, о которых вам уже не один раз рассказывали. А в купе с возможностью быстрой разработки, быстрым внедрением собственных инструментов в среду и многочисленными инструментами среды из коробки, он является мощным инструментарием.

Не говоря уже о том, что язык развивается семимильными шагами.

Развитие — это хорошо. Что там нового и, желательно, отсутствующего в большинстве прочих языков запилили?

А для начала необходимо указать, что имеется сейчас из того, чего нет в других языках.
1. Скорость и лёгкость разработки. Софт с GUI писать одно удовольствие.
2. Масса коробочных решений. Я написал софт для просмотра 3D панорам в 20 строк, в только что установленной среде.
3. LiveBindings и прочее

Ну а что нового... Во-первых я не знаю с какого момента для вас что-то будет новым. Если вы знакомы с делфи только по Delphi 7... То разговор будет долгим.

Извиняюсь, а можно на этот софт для просмотра 3D панорам в 20 строк посмотреть? Лучше, конечно, в исходниках, ну или в виде HOWTO?

В среде есть штатные средства для создания 3D сцены. Как в юнити (почти). Исходника нет, т.к. он перерос в большой проект. Шаги следующие:

В дизайнере:

  1. Добавляем на форму Viewport (сцена).

  2. На сцену добавляем сферу.

  3. На сферу помещаем материал (без освещения).

  4. Приближаем камеру чтобы оказаться внутри сферы.

  5. Кидаем компонент диалогового окна выбора файла

  6. Добавляем кнопку

Выбираем сферу и добавляем её обработчик событий OnMouseMove, OnMouseDown, OnMouseUp

В коде:

  1. OnMouseDown - флаг, что нажата мышь и запоминаем координаты мыши

  2. OnMouseUp - снимаем флаг

  3. OnMouseMove - 5-6 строк для поворота сферы в зависимости от смещения мыши

  4. На нажатие кнопки выполняем диалоговое окно, выбранный файл загружаем в материал (3 строки)

Готово. Получаем кроссплатформенный софт для просмотра панорам. Можно собрать под винду, андроид и ios из коробки.

Это всё штатными средствами без каких-либо сторонних библиотек.
Есть и более быстрый способ. Есть репозиторий компонента, который вмещает в себя все вышеперечисленные шаги (+некоторые визуальные удобства, плавный скрол и т.д.).
С ним достаточно будет кинуть компонент на форму и добавить кнопку выбора панорамы. Т.е. 3 строки.

Могу скинуть ссылку на видео. Там проделанная работа за 3 дня. Все данные идут из сети. Софт собирается на андроид. Нацелен на планшеты. Но только в вк
https://vk.com/video58553419_456239669

Панорамы в видео, к слову, тоже сделаны в программе написанной на Delphi. Речь о программе для дизайна интерьера. И она написана как раз на Delphi 7. Т.е. работа со сценой и рендеринг всё сделано в одной программе.

Собственно я заморочился и добавил в гит. Код, который писался находится только в файле .pas (и то только то, что в процедурах внизу). Остальное автоматически генерируемые файлы.
https://github.com/HemulGM/Pano3D

Спасибо, посмотрю. Добрался глянуть на работе, что есть в D10.3 (легальной). Нашёл там упомянутые ключевые слова, TViewPort3D и даже TForm3D, если визардом создавать сразу 3D приложение.

Не обязательно создавать TForm3D, TViewPort3D можно добавить в любой момент в любых кол-вах (в FMX конечно же)

Да, я понял, что TViewPort3D можно и на FMX.TForm кидать. Вот пока не изучил, что же даёт TForm3D по сравнению с TForm. Надо читать, может что полезное из этого родится.

TForm3D - это вся форма - 3D сцена

Тоже очень привязан к Паскалю. До сих пор продолжаю поддерживать приложение, первый вариант которого заработал еще в 1991 году под Turbo Pascal 5.5. Приложение предназначено для графического исследования динамических систем, задаваемых системой обыкновенных дифференциальных уравнений. Ныне это все работает во Free Pascal 3.2.0 (графическая часть) и Lazarus 2.0 (база данных динамических систем). Особенно меня радует, что до сих пор можно пользоваться почти без изменений кусками кода, написанными 30 лет назад

image

Вот ролик, в котором показан пример исследования динамической системы «с нуля». Конечно, заметно, где код старый, а где поновее. Старая, графика, к сожалению, медленновата, но для многих применений её достаточно

Исследование динамической системы («гиперхаос Рёсслера»)


Паскаль таки хорош в качестве языка «на всю жизнь»

Красивый ролик. Спасибо.

Весь этот код, запросто можно переделать на C/C++

В добрый час! Если уж вы это произнесли, то, когда переделаете — сообщите, пожалуйста, здесь, в комментариях, о завершении работы и выложите результаты.
Если говорить серьезно, то в своём приложении я практически не пользуюсь никакими сторонними компонентами, а у вас в процессе переделки это может и не получиться. В любом случае, интересно будет взглянуть на то, что у вас выйдет.

Не охота мне переделывать. Да и смысла нет. И времени тоже. Вроде даже специальные утилиты у Borland были, для миграции исходников между delphi и cpp builder

Я тоже не очень понял, зачем вдруг мой код нужно переделывать на C/C++. Повторю, что он продолжает работать, будучи написанным 30 лет назад (под Windows 10 тоже). Если вы имеете в виду, что C/C++ дадут какие-то уж очень большие преимущества в разработке подобного рода, то в этом у меня большие сомнения. Использование самих по себе C/С++ или ООП не даст большого выигрыша по сравнению с Паскалем там, где нужно писать компилятор формул или процедуры аналитического дифференцирования. Конечно, можно пользоваться сторонними компонентами, но той свободы, которую получаешь, написав всё самостоятельно, при этом не получишь
Использование самих по себе C/С++ или ООП не даст большого выигрыша по сравнению с Паскалем там, где нужно писать компилятор формул или процедуры аналитического дифференцирования.

Правильно, для этого лучше брать языки из ML-семейства. Компиляторы и тому подобное на них очень приятно писать.

Правильно, для этого лучше брать языки из ML-семейства. Компиляторы и тому подобное на них очень приятно писать
Компилятор выражений — только часть моего приложения, важная, но не едиинственная. Кроме того, нужно достаточно быстрое выполнение множества операций с плавающей точкой, действия с матрицами, возможность динамического выделения/освобождения памяти, работа с графикой. Для всего этого нужен был универсальный язык. Паскаль для этого подходил уже очень давно, и до сих пор он позволяет относительно просто дополнять систему, а также без проблем мигрировать на новые версии компиляторов и новые версии ОС
Кроме того, нужно достаточно быстрое выполнение множества операций с плавающей точкой, действия с матрицами, возможность динамического выделения/освобождения памяти, работа с графикой.

Тот же хаскель, по-вашему, этого не умеет?

Тот же хаскель, по-вашему, этого не умеет?
Понятия не имею. В 1991 я ни про какие Хаскели ничего не слышал, пользовался тем, что было просто и доступно. За 30 лет настоятельной необходимости в чем-то, кроме Паскаля, и не возникло. Для доказательства того, что Хаскель существенно лучше, нужно было бы написать на нём подобную систему, которая была бы существенно лучше в чем-то (быстрее, или работать на совсем уж разных ОС), да еще и чтобы она работала на всех промежуточных версиях Windows (и даже MS DOS)

Ну если всю жизнь заниматься одной программой, то, конечно, необходимости в других языках не возникнет. Они будут даже вредны — действительно, зачем переписывать уже работающее?

Ну если всю жизнь заниматься одной программой, то, конечно, необходимости в других языках не возникнет. Они будут даже вредны — действительно, зачем переписывать уже работающее?
Это приложение — развлечение для души, и я привожу его историю как пример, иллюстрирующий основную мысль публикации — почему автор до сих пор не отказался от Паскаля. Моё мнение — у автора есть для этого основания

На вопрос «почему не отказался от паскаля (кобола, етц)» вполне себе хорошим является ответ «легаси». Серьёзно, без иронии.


Однако, чаще всего интересен вопрос о том, какую технологию выбирать для следующего проекта. Если бы вы сегодня эту систему делали с нуля, то вы бы тоже выбрали паскаль?

Однако, чаще всего интересен вопрос о том, какую технологию выбирать для следующего проекта. Если бы вы сегодня эту систему делали с нуля, то вы бы тоже выбрали паскаль?
Не могу ничего ответить, я не полиглот в отношении ЯП. Примерный аналог моего отношения к этому — это похоже на поддержание на ходу какого-нибудь древнего, но красивого автомобиля, при этом автомобиль должен быть сделан так, чтобы это позволить

image
и даже MS DOS


Где в 2021 году держат MS-DOS и с какой целью, интересно знать ;)
Где в 2021 году держат MS-DOS и с какой целью, интересно знать ;)
Наверное, нигде не держат, я говорю о приложении, которое работало под MS DOS, работает под Win10 и является полезным до сих пор
Тут дело не в выборе правильного языка, а в Microsoft, которые протянули бинарную совместимость с DOS аж до Windows 10. Программа на Ассемблере под DOS тоже должна работать в Windows, why not. Если прямого доступа к железу не использовать.
Программа на Ассемблере под DOS тоже должна работать в Windows, why not. Если прямого доступа к железу не использовать.
Интересно бы взглянуть на такую программу на Ассемблере, особенно без использования доступа к железу

Hello world с выводом через int21.

Нет, я имею виду програму на Ассемблере с обработкой формул, матричными операциями и элементами трехмерной графики
Можно поискать среди старинных демосцен или игр. Они написаны на ассемблере, внутри много матричных операций, некоторые из них, я уверен, запустятся и под windows.
Но это же совершенно не значит, что ассемблер х86 является однозначно наилучшим выбором для долгоиграющего проекта.

С целью отсеивать новые языки, конечно же.

Я недавно устроился в одну организацию. Есть программы под DOS. Причём, просто взять их и выкинуть не получится. Уж очень сильно на них завязано.

Выигрыш даст. Это больше заказов. Заказчики требуют чтобы было на C++. И ни на какие дельфя и паскали не согласны. Да и ещё за спиной у виска покрутят пальцем.

Это приложение — для души, я уже писАл об этом. Его можно использовать в готовом виде, большую часть часть фич — бесплатно (на самом деле, это приложение SHAREWARE с пробным периодом, отнюдь не железобетонной защитой и символической оплатой за официальную регистрацию). Те, кто крутят пальцем — пусть крутят, тем, кто утверждает, что
Весь этот код, запросто можно переделать на C/C++
можно ответить только — ну, запросто переделайте и покажите, что получилось. Можно считать это резьбой по рисовому зёрнышку, на такое заказчиков, конечно, немного
В хобби-проектах можно всё, хоть и brainfuck-процессор из рассыпухи собирать. Но слесарь-одиночка крупный проект просто не вытянет. Linux, к примеру, выехал не на гениальности и работоспособности Торвальдса, а на том, что ему удалось организовать командную работу.
Не претендую на славу Торвальдса, замечу только, что мой, как вы выражаетесь, хобби-проект, существует примерно так же долго, как и Linux. А крупных проектов, которые не просуществовали и пару лет, я видел достаточно, как и тех, за участие в которых должно быть стыдно

Ну не всем же крупные проекты делать. А в мелких , тот же C++ крайне неэффективен против Паскаля/Дельфи.

Можно один и тот же код из примеров посмотреть на Delphi и C++ Builder, неужели кому-то второй вариант кажется более лаконичным и удобочитаемым?

procedure TForm1.MyButtonClick(Sender: TObject);
void __fastcall TForm1::Button1Click(TObject *Sender)

Для души, это другой вопрос. Для души это правильно. Я вот недавно для души, пентиум первый собрал. Работает. Многие спрашивают, зачем он тебе? Мог собрать посовременней.

Только производительность Делфи может сравниваться только с срр. Остальные языки проигрывают.

Делфи может сравниваться только с срр. Остальные языки проигрывают.

Можно, пожалуйста, ссылку на независимое измерение для веб-приложения? Ну не знаю там, что-нибудь на манер вот этого: https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite (где я ни дельфи, ни паскаля не вижу)

Я бы не хотел на этом сливаться, но отсутствие веб фреймворков на Делфи в этом бенчмарке не говорит о его производительности. Я не использую сам делфи как веб сервер. Хотя на нём есть не мало веб фреймворков. Я был бы рад увидеть их в тестах, но создавать тестовое веб-приложение я не планирую.

Можно провести обычные синтетические тесты и сравнить скорость. Но в сети уже есть сравнения.

Хотя на нём есть не мало веб фреймворков.
Но в сети уже есть сравнения.

Вот я и прошу: можете дать ссылку на независимое сравнение производительности веб-фреймворка на Delphi с веб-фреймворками на других языках?

Почему именно веб-фреймворки? Это вообще не популярная вещь на Делфи. И я уже сказал, я не использовал веб-фреймворки (только для фронта). Я не знаю где есть тесты.

Потому что вы сказали о производительности языка без указания сценариев, сказав, что остальные языки проигрывают. Вот я и заинтересовался, стоит ли рассматривать так расхваливаемый вами Дельфи для моих задач.


Пока выходит, что бесполезно.

Как связана производительность языка и наличие в нём конкретных фреймворков? Язык обладает высокой производительностью. Высокая производительность ни как не гарантирует в языке наличие по умолчанию веб-фреймворка.

Возьми делфи, веб-фреймворк, протестируй если тебе интересно. Я знаю его производительность в других задачах.

Вы утверждаете, что Delphi обладает высокой производительностью. Ни одной ссылки, ни одного примера (кроме каких-то абстрактных «обычных синтетических тестов») от вас не последовало. Когда вас спрашивают про конкретную область применения — вы отмахиваетесь, мол не для того язык используют. Так для чего же? Можете подкрепить своё утверждение о производительности на примерах, желательно из реального мира, а не на голой «синтетике»?

Все продукты auslogic сделаны на Delphi

Как связана производительность языка и наличие в нём конкретных фреймворков? Язык обладает высокой производительностью.

Я не очень понимаю, что такое "производительность языка". У меня решения, написанные на одном и том же языке, могут отличаться по производительности на порядки. Так что меня интересует производительность конкретного решения на конкретной задаче. Вот TechEmpower запарились и сделали такое сравнение для типовых веб-фреймворков.


А "производительность языка" — это что-то абстрактное, что я никогда в своих задачах не увижу.


Возьми делфи, веб-фреймворк, протестируй если тебе интересно.

Не, мне не интересно тратить свое время на тестирование производительности решения на языке, который может быть даст мне выигрыш в производительности, но ни в чем остальном (из того, что я видел, конечно) не выигрывает у подходов, которыми я сейчас пользуюсь.

В Делфи совсем не давно появилась возможность собирать код под Линукс. По причине того, что в сервер в 80% - это сервер на Линукс, а компиляции под линукс у Делфи не было - нет и большого количестве веб-фреймворков. Это сейчас есть RESTfull и прочие фреймворки, работа которых возможна в Docker.

Именно по этой причине нет того, что вы от меня требуете и именно по этому Делфи вам на данный момент не подходит.

… хотя казалось бы, 80% моей разработки идет под Windows, и линкус меня вообще не интересует, Дельфи все равно мне не подходит? Забавно.


Так все же, что с производительностью-то? Или не было, забыли?

Высокая скорость работы обусловлена тем, что язык компилируемый, строго типизированный и позволяет передавать параметры функций на стеке. Человек, с которым я общаюсь требует конкретное тестирование как веб-сервиса. Если вам интересны тесты скорости - погуглите. В наше время это не так и сложно.

Высокая скорость работы обусловлена тем, что язык компилируемый, строго типизированный и позволяет передавать параметры функций на стеке.

Дельфи тут не одинок совершенно, не повод считать его самым быстрым, или даже "только он и cpp".


А, главное, в контексте реальных задач это часто не имеет значения (смотрите результаты тестов выше).


Если вам интересны тесты скорости — погуглите. В наше время это не так и сложно.

Так я погуглил, ничего не нашел.

Производительность, да. И не только. Он во всём превосходит все новомодноые языки тип питона. Вот только заказчикам этого не обьяснить. Им нужен питон и точка. Никаких других доводов они и слышать не хотят. Спорить с ними бесполезно. Лучше под них приспособится, и зарабатывать деньги. Чем быть гордым но нищим разработчиком Delphi.

Если кто-то попросит крупный софт с GUI на питон я посмотрю, как ты будешь это делать

PyQt?

Да можешь хоть tkinter использовать. Только смысла в этом не будет от слова совсем.

Насмешили. :) Браузер + сервер + движок на питоне. А вот сделать на delphi серверное приложение сможет не каждый.

А вы погуглить что такое TMS Web или uniGUI

И речь идёт о клиентском ПО, а не о веб сервисе.

т. е., по вашему веб сервис не может быть клиентским ПО?

Он во всём превосходит все новомодноые языки тип питона.

Вот прямо вот во всем?


А C# вы тоже считаете новомодным языком, на всякий случай?


Вот только заказчикам этого не обьяснить. Им нужен питон и точка.

Ну, я могу их понять: у них есть набор требований по поддержке, куда может быть включен конкретный язык. Мало же найти того, кто софт разработает, надо еще иметь возможность найти кого-то другого, кто этот софт будет поддерживать.

Для меня да. Суть не в новомодности. А суть в том что работодателей, ищущих программистов именно на Delphi очень мало. Питон я привел для примера. Пусть будет Java. Вот, (к примеру), упёрся заказчик, мне надо именно на яве. Никакие delphi мне не нужны.

Для меня да.

Не, если для вас — то да, с этим сложно аргументированно спорить. Да и не нужно.


А суть в том что работодателей, ищущих программистов именно на Delphi очень мало.

Я выше уже предположил, почему такое может быть.

Ну не запросто. Времени уйдёт немало и непонятно на что.

Правда я в своё время разрабатывал автоматический транслятор в Си(без плюсов) для микроконтроллеров. Но там код требует иногда правки вручную, а чтобы 100% автоматически делалось, это требуется слишком много времени, да и мало кому нужно.

А на PascalAbc.net не пробовали откомпилировать?

Нет, не пробовал. Я об этом варианте Паскаля ничего и не знал, прочитал это и ужаснулся! Наверное, и не не буду пробовать

Ну с 2018 года там много глюк исправили. И уже и тогда эти глюки касались тех вещей, которые не были в Турбо Паскале. Его сейчас активно используют в школах, так что если бы были серьёзные проблемы с переносом программ, то это было бы широко известно. Поэтому если вы активно не собираетесь использовать "новые фичи", то всё должно работать.

Немного не в тему. У самого установлен Delphi 7, но честно забыл когда последний раз запускал. Буквально на днях вышла новая бесплатная версия: https://www.embarcadero.com/ru/products/delphi/starter

Уж очень быстро привыкаешь к хорошему и новым плюшкам.

Приходилось переносить свои старые проекты с 7-ки на 10.2 в среднем 1-2 дня работы (правда проекты не особо крупные).

ps О delphi 7 самые теплые воспоминания (студенчество).

Сейчас точно не вспомню, но минимум. Сторонних компонентов практически не было, GLScene попутно обновил до последней версии и все заработало.

"минимум" больше нуля? И один баг поймать или увидеть, что багов нет, много времени уходит.

Багами назвать трудно, в основном были несоответствия типов и пришлось немного код переписать.

Ага попробуй в эмбаркадеро сделать так s:=chr(77); ord(s) 77 не получится. Бл. дня два бился, пока не понял в чём дело. Свои функции пришлось писать.

Видимо уже исправили.

А в чем дело?

Я насколько помню там ошибка , если больше $80 число. Тогда надо писать свою обёртку.