Комментарии 334
Грустная история, на самом деле. История о полезном коде, который надо бы транслировать подо что-то современное, но для этого надо выучить ещё и это капризное современное.
И тот полезный код превращается в чемодан без ручки -- тащить неудобно, а выкинуть жалко.
Так досадно, что так и не появилось надёжных средств автоматической миграции с D7 куда-нибудь в RAD Studio! Вот не понимаю, это такая сложная задача, или просто сообщество уже вымерло и никому это неинтересно?
Кобол и фортран старше, но они живы.
Они не являлись "языком одной корпорации"
Первый ОО Pascal Борланда был турбо 5.5. MS в это же время выпустил свой (названия не помню). Продукты столкнулись. В Byte-en про это большую статью напечатали. Борландовский победил. А У.Гейтс очень обиделся на Pascal.
У MS был Quick Pascal.
И вроде после появления TP 5.5, максимум 6.0, Microsoft из этой гонки вышел.
В 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. А потом они все потерли.
Сейчас — да. А что м.б. через несколько лет никто не знает. ИМХО история DEC очень поучительна.
А что может случиться через несколько лет с репозиторием, который представляет собой папку в вашей файловой системе, чего не может случиться с любой другой папкой в вашей файловой системе?
Зачем мне системама контроля версий? Проги с оригинальными алгоритмами храню с первой версии. Т.к. и она может оказаться нужной. Пройдет время и вылезет пропущенный баг. Возникнет вопрос на какой версии он был пропущен? М.б. в первой этого бага не было и он завелся в результате следующих изменений.
Так команда git bisect именно эту задачу автоматизирует.
Бывают случаи, когда человек правит код и его отвлекают — и он попал по клавише не в том месте — выражение изменилось — вместо плюса минус. Но последущие тесты и работы с прогой этого места не коснулись. В таком случае стоит глянуть правильно ли работает это место в первых версиях.
Как тут поможет git bisect?
А тут поможет банальный просмотр изменений перед коммитом, который, например, показывает sublime merge. Вы увидите во-первых, файлы, в которых произошли изменения, во-вторых, сможете хоть построчно эти изменения принять/откатить до того, как ваша работа уйдет в коммит.
Все cvs разных сортов автоматизируют утомительную ручную работу с find, diff, cp, patch и другими утилитами, которые можно использовать для того же самого, хранят историю, позволяют вести работу в нескольких ветках над одним и тем же кодом, обмениваться сделанной работой, и все это без облаков и сетевых служб.
Зачем мне системама контроля версий?
Ровно для того, чтобы иметь доступ ко всем версиям и их истории, как и любому другому разработчику.
Проги с оригинальными алгоритмами храню с первой версии. Т.к. и она может оказаться нужной.
Вот как раз в этом случае СКВ прекрасно помогает: переключились на первую версию, увидели весь код, как был.
Возникнет вопрос на какой версии он был пропущен?
git bisect, как вам уже не раз написали.
Я так понимаю, вы путаете git (программу) и GitHub (облачный сервис).
Читаю в Вики:
Git — распределённая система управления версиями.
Репозиторий Git бывает локальный и удалённый.
Я и решил, что Вы мне облако советуете. А с версиями (локально) у меня обычно нет проблем, но мусор, если нужно предпочитаю разгребать руками.
Специальная программа для незаведения мусора типа my_program_YYYYMMDD_final_2_fixed_3.arj с этим справится ещё лучше ;) А если рабочих мест >1, мусора возникает ещё больше.
Рекомендую таки попробовать. Денег за это не берут, все что нужно - время от времени запускать tortoise hg и нажимать кнопку commit.
C git/mercurial ничего не случится. Это системы контроля версий. Репозиторий хранится локально. От потери данных сам по себе не спасёт (нужны бекапы и т.п.), но от кучи дубликатов вполне может помочь
Опечатка: не 1Гб, а 1000Гб. Отвлекли при наборе. Приношу извинения.
Когда я в последний раз интересовался этой темой, мне советовали поэтапно переводить через каждую следующую версию, этапов в 5. Надо попробовать ваш рецепт..
Помнится, мы лет двенадцать назад переводили кучу проектов с Delphi 6 на Rad Studio 2007 и в общем-то оно заняло пару дней с минимумом правок.
Переход с версии на версию Delphi/Rad studio достаточно прост, но может быть все-таки сильно осложнен двумя проблемами.
Первая и часто почти непреодолимая - сторонние компоненты, заточенные под определенную версию. Часто без исходных кодов и без развития с вариантами под новые версии среды разработки.
Вторая легко преодолима, но очень трудозатратная - строки. К счастью, проблема проявляется только один раз в жизни проекта. Был там момент перехода на уникод, для перехода через который приходилось очень много переделывать с этими самыми строками.
Остальное там достаточно просто решаемо.
Автору можно посоветовать: попробовать бесплатную Delphi Community Edition, новая версия которой вышла буквально вчера. Либо Lazarus, где UI по умолчанию очень привычен для пользователя Delphi 7, однако это современная IDE, с современным компилятором FreePascal и работающая везде, в том числе под Linux.
Это "современное" устаревает со страшной силой и супермодное уже через пару лет выглядит смешным. Паскаль как мертвый язык хотя бы не меняется.
FPC не спасет аксакалов?
Остаётся отдать должное стойкости людей, отказывающихся принять прогресс.
И я не про текущие технологии и реализации, а про то, как они будут искать тех, кто примет и продолжит.
Чужие библиотеки с исходниками, и даже купленные с исходниками - совершенно не гарантируют что они не будут заброшены авторами, и что вообще автора можно будет найти. И самостоятельно мигрировать чужую библиотеку на новую версию Delphi - тоже тот еще квест. На этом фоне радуют FastReport - многие годы никуда не деваются, а последняя версия все еще работает и на Delphi 7 и на Lazarus.
А извините, у каких языков компиляторы полностью совместимы?
И полностью обратно совместимы?
плюсы близко к этому
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.
Попробуйте впихнуть в значимое имя фразу: загрузить из архивного файла, записи для товарных вагонов, расшифровать их, пустые вагоны добавить в таблицу свободных вагонов.
Так даже впихивать не надо.
Тут явно напрашивается разбить это все на функции, которые можно назвать одним-двумя-тремя словами.
Тогда код будет чуточку более самодокументируемым и чуть менее нуждающимся в комментариях :)
Разбить на ф-ции проще простого. И код будет имнть кучу повторяющихся фрагментов:
загрузитьИзАрхивногоФайла(записиДляТоварныхВагонов);
расшифровать;
пустыеВагоныДобавить (таблицаСвободныхВагонов);
Если фрагмент повторяется многократно, то его обычно прячут в ф-цию. Получим:
загрузитьИзАрхивногоФайлаРасшифроватьПустыеВагоныДобавить(записиДляТоварныхВагонов, таблицаСвободныхВагонов);Будем честными, оба варианта выглядят странно, потому что не очень понятно, где же чья ответственность. У вас правда одна функция возвращает два слабо связанных набора данных (товарные вагоны и свободные вагоны)?
Так давно никто не делает. Всё это решает ооп, где всё сильно упрощается [впрочем, и усложняется тоже].
Если ооп, то у вас всё это разлетится на кучу объектов, где совершенно не будет монструозных длинных имён.
Объект Файл, у него функция Файл.Загрузить();
Абстрактные объекты записей будут, от них наследованы ваши записи.
У вас там выше не товарные вагоны должны добавляться, а записи.
СписокЗаписей.Добавить(Запись); А то что под записью это запись товарного вагона - за это и отвечает ооп. И не важно что у вас там - товарные вагоны или не товарные, буратины или боенги с кирпичами, ооп разгребёт всё само, на то оно и ооп.
И т.д. и т.п.
Если фрагмент повторяется многократно - то зовут вменяемого программиста, который накорячит архитектуру под определённый язык и сообразит библиотеку базовых типов под это всё дело, а так же основные базовые действия с типами, их преобразования и т.д. Обычно оно называется фреймворком.
Не использование ооп там где это действительно может помочь - глупейшая ошибка. Впрочем, использование ооп там где оно нафиг не нужно и можно обойтись без ооп - ещё более глупая ошибка.
Однако же т.к. автор - учоный [вроде бы], то и спрашивать с него нечего. Понять, простить.
Разбить на функции проще простого можно тогда и только тогда, когда нет абстракций. А у учоных их нет) Учоный мир живёт на композициях, потому то оно и не интересно.
Специально для учоного:
Понимание - это сравнение. Но механизмов сравнения абстракций у учоного мира не существует. Отсюда все беды. И эти беды у программистов отсутствуют.
Как обычно пример на пальцах. У меня знакомый физик есть, и он упоротый как любой учоный. Я ему так и смог объяснить что Солнце - это не звезда, а имя собственное. Вот хоть тресни - не получается. А ведь человек публикуется в очень крутых местах. А уж собрать базовую систему типов астрономических объектов для учоного - это вообще нерешаемая задачька по определению.
Причём понятное дело что Солнце как имя собственное должно быть приляпано как интерфейс к абстракции астрономического объекта, смех в том что в этот интерфейс ещё и абстракции народности надо забрасывать, ибо всё у всех называется по-разному.
И т.д. и т.п.
Я высупал в защиту ООП. И исполюзую ООП. Но при разработке нового алгоритма ООП не всегда удобно. И для описания м.б. не очень удобно.
И да, я "учоный", но многие мои проги к науке отношения не имеют.
"Зачем тут вообще ООП"
"в подавляющем большинстве случаев ООП — это такие модули"
"X as File"
Гонг вопрос: где тут ооп, а где тут нет ооп?
Всё смешалось... Кони... Люди... (с) кто-то
И объекты в окамле малопопулярны, похоже, потому что львиная доля случаев их применения покрывается старыми добрыми (в ML) модулями.
Повторяющиеся вызовы функций все же несколько лучше повторяющегося кода их реализации, сопровождающегося комментарием.
Чем лучше?
Да, это так. И я это имел в виду, когда сказал про повторы фрагментов. Но речь шла об огромных именах для замены комментов.
При грамотной декомпозиции, огромные имена просто не понадобятся
Ну и как впихнуть в значимое имя фразу: загрузить из архивного файла, записи для товарных вагонов, расшифровать их, пустые вагоны добавить в таблицу свободных вагонов? Так чтобы было понятно какие действия совершает прога.
свободныеВагоны.добавитьИзАрхивногоФайла(...)
Какая разница, расшифровывает оно их или нет?
Очень большая. С шифрованными записями прога не сможет работать.
Это значит, что при чтении вы их всегда расшифровываете, и именно поэтому совершенно нет необходимости это указывать в названии операции.
Не значит. Нпр., для ускорения поиска по БД поле "тип записи" можно не шифровать. Если тип записи = "ТВ", то это запись товарного вагона.
Но у вас не операция поиска, у вас операция загрузки свободных, а ее нельзя сделать без расшифровки. Пойнт в том, что для получателя, которому нужен список свободных вагонов, пофиг, пришлось вам их расшифровывать, или нет. Какая разница?
Есть: загрузить из архивного файла, записи для товарных вагонов. Это может значить найти и загрузить.
Пойнт в том, что для получателя, которому нужен список свободных вагонов, пофиг, пришлось вам их расшифровывать, или нет.
Согласен, что конечному юзеру пофиг. А программисту который пришел на место разраба очень важно понять, почему в методе добавитьИзАрхивногоФайла после чтения идет много строк кода. Напомню, эта ветка обсуждения началась с идеи отказа от комментов, и замены их именами.
А программисту который пришел на место разраба очень важно понять, почему в методе добавитьИзАрхивногоФайла после чтения идет много строк кода.
Много строк кода вынесены в функцию DecryptDataFromDB, например. Программист понимает, что это что-то связанное с расшифровкой.
Программисты — они понятливые, но вместо того, чтобы в одной строке коммента прочесть, программисту нужно бегать по разным функциям. Что быстрее? эргономичнее?
Нет, не надо ему никуда бегать.
Покажите уже пример, а то мне кажется, мы друг друга не понимаем.
Я показал:
//загрузить из архивного файла, записи для
//товарных вагонов, расшифровать их, пустые
//вагоны добавить в таблицу свободных вагоновНепонятно. Где этот комментарий написан-то? Как он с кодом соотносится?
Cоотносится, как и всякий комментарий. Нпр.:
begin
loadFile;
//загрузить из архивного файла, записи для
//товарных вагонов, расшифровать их, пустые
//вагоны добавить в таблицу свободных вагонов
nextProc;
end;Все равно не понимаю. Где выполняются все перечисленные действия?
В процедуре loadFile; просто формат Хабра не позволяет разместить этот вызов и следующий комментарий в одну строку. На практике такой проблемы нет.
Т.е. этот комментарий видит тот, кто вызывает процедуру, а не тот, кто ее правит. Тогда:
- его придется повторять (и поддерживать актуальным) везде, где процедура вызывается
- он содержит ненужную информацию (выше уже обсудили, что вызывающему нужно только знать, что и куда будет добавлено)
- не решает озвученную вами же проблему с "программист, который пришел править
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 не завозили?
Завозили, но речь не о том. Речь про отказ от комментов и про использование только значимых имен. Чем больше строк между такими именами — тем труднее читать, тем привлекательней комменты.
Неа, комменты все еще не привлекательны, потому что они требуют дополнительного труда по поддержанию, и все еще не отвечают на вопрос "что происходит в этом месте кода".
Ну ИМХО это уже философский вопрос: насколько реальность отвечает нашим ожиданиям, Статья про разработку новых алгоритмов, и, в этом случае, комменты особо важны: читаем, что хотел автор, и смотрим код: что у него получилось.
Статья про разработку новых алгоритмов, и, в этом случае, комменты особо важны: читаем, что хотел автор, и смотрим код: что у него получилось.
Вот именно поэтому комменты надо писать там, где алгоритм, который нетривиальный, и не надо писать там, где инфраструктура.
В вашем примере, который про загрузку файлов, как видим, комментарии избыточны.
… то тоже легко, более того, хорошо видно, когда-таки началось дешифрование. Особенно если не забывать пустые строки вставлять.
А еще можно обработку ошибок переделать, и оно обратно схлопнется.
Пустые строки сродни комментам?
Кроме обработки ошибок, потом может новый код добавиться.
Пустые строки сродни комментам?
Нет, пустые строки сродни разделению текста на абзацы.
Кроме обработки ошибок, потом может новый код добавиться.
… а вы в этом случае комментарий сверху тоже обновите?
а вы в этом случае комментарий сверху тоже обновите?
Конечно.
Вот это и есть та самая лишняя работа. Намного выгоднее вынести этот лишний код в отдельную процедуру, сохраним читабельность.
И чтобы узнать, что делает этот код нужно лезть в отдельную процедуру.
И чтобы узнать, что делает этот код нужно лезть в отдельную процедуру.
Нет, достаточно прочитать название процедуры.
Ага, название процедуры: loadFilePrintErrorDecrypt...
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.
Это никак не помешает программисту вызвать 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 байт. Но конечно, если собирать в дебаг-режиме, с настройками по умолчанию, которые пихают вообще всё, что можно, в бинарь...
Не весь MS visual C++, а только tools.
Которое весит мегобайт 900. И хрен поймёш как настроить потом всё это.
Ну да, весит много. Но у вас разве нет свободного гига для нужд разработки?
Плюс, ничего больше настраивать не надо.
Пакет conan который я делал где чисто под 1 платформу компилятор и хидеры, для последней версии 300 мб в распаковке на диске.
Но компилятора мало, скорее всего еще Windows SDK нужен.
Опять же под одну платформу (х64) все необходимые файлы в распаковке примерно 500 Мб.
Ну и сравнить например с IDE Qt Creator — где нет ничего (ни компилятора, ни дебаггера, ничего, просто редактор со всеми ништяками) — 600 Мб на диске.
Не выглядит как что-то на что стоит жаловаться. я бы только на clang жаловался, какого он жирный такой)
p.s. ну а настройка это да, это смех — установил компилятор и все, популярные ide подхватят все сами. для консольки — vsvarsall.bat дернул, шо еще надо-то…
Да не хочу я больше это изучать. Вот C/C++ другое дело. mingw скачал и установил. Больше никаких манипуляций. Если конечно не понадобится что то вроде qt.
По умолчанию почему-то ставится msvc-версия. Если насильно ткнуть при установке в gnu-версию, то не надо ничего, рядом сам ставится mingw.
Он может использовать и gcc. Не обязательно visual c++.
Насколько помню, в 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"
ну и, если необходимо, добавить в этот список какие-то другие используемые шрифты.
Почему лень. Я упоминал OpenCV, CUDA — учил самые свежие версии. Очень много времени у меня уходит на графы — много читаю интересных статей. Ну, и на химию.
А хорошим химиком и физиком можно быть? Много людей работают в физхимии, в Москве 2 НИИ РАН: физхимии и химфизики. Получается работать на стыке наук. Почему Вы думаете, что невозможно работать на стыке химии и CS?
Это Вы не обижайтесь: Вы в розовых очках полагаете, что использование новейших технологий делает Вас хорошим программистом.
И тут явно видно что вы не справляетесь
Не видно ;) Статья как раз о том, что справляется со своими задачами с помощью устаревшего языка.
Версия языка Delphi обновляется каждый квартал. Delphi давно не привязан к одной платформе (Windows) и позволяет писать и на Linux/Android/iOS/MacOS/Windows один кроссплатформенный код. Давно умеет в быструю и простую асинхронность (TThread/TTask/TTaskPool) (куда лучше чем async/await, например в шарпе).
Дизайнер окон мощнее любого из существующих (погуглите на эту тему, если есть сомнения).
Помимо всего этого, погуглите Delphi TMS Web, Delphi uniGUI.
На псевдокоде. Нпр., если в алгоритме 2 цикла (1 вложен), и делают m и n шагов, то в наихудшем случае алгоритм сделает mn шагов.
если в алгоритме 2 цикла (1 вложен), и делают m и n шагов, то в наихудшем случае алгоритм сделает mn шагов.
По разному бывает. Например, перевоплощение массива в бинарную кучу выглядит как O(n*ln(n)) - каждый элемент надо "просеивать", что вроде как ln(n). А по факту выходит O(n) на всё про всё.
Верно. Но если у нас граф с n вершинами и "координаты" текущей вершины (i,j) меняют два цикла от 1 до n, то можно сделать вывод, что в матрице смежности каждый элемент будет просмотрен 2 раза.
Из этого следует, что подзадача просмотра м-цы смедности решается корректно. Аналогично для других подзадач.
Переведу на Pascal:
var sink :integer;
begin
for i:=1 to n do
for j:=1 to m do
sink := arr [i,j];
end;Если правильно перевел, то правильная.
Согласен с автором.
FreePascal у меня, конечно, есть, но не пользуюсь. EmbarcaderoSydney тоже живёт в виртуалке. Для прототипов предпочитаю delphi7; живёт в виртуалке windows7 и проблем с юникодом не наблюдается. Получаются быстрые и надёжные прототипы, хоть в многопотоках, хоть в процессах, линкуется с чем угодно в себя и из себя.
Зачем учить пытон(тем более конкретно третий) сегодня, если завтра его сменит крокодил ?
P.S. Паскалем не ограничен = использую языковые инструменты в зависимости от задачи.
Вот тут бы пригодился транслятор из Паскаля в Python pas2py
Delphi-7 напоминает мне Windows XP. Устарел, но работает. И иногда проще ничего не трогать, если он выполяет все цели, для которых используется.
Спасибо за замечание. Добавлю в статью. Я уже подзабыл "прелесть" медленных компиляторов.
Современный язык с реплом даст вам те же ощущения,
Я не знаю про существование современных языков с реплом, которые несколько сотен тысяч строк компилируют за доли секунды, но даже если бы были, для тех же ощущений мне понадобится ещё и IDE, где я могу мышкой нарисовать UI, причем с живыми данными в дизайнтайме.
Для своего времени Delphi-7 был реально очень хорош, на самом деле.
Такое ощущение, что вы пытаетесь оправдать свою лень освоить какой-либо другой ЯП. Текст полон стереотипов. Вот это например:
Pascal-образный (Pascal-like) псевдокод интуитивно понятен (всем кто знаком, хотя с одним универсальным ЯП)
конечно же, не использовать пресловутый goto
Да, именно лень является здесь основным мотивом:
Понятно, что возьму эти процедуры из своего старого кода. Но почему Delphi-7, а не более новое? — К сожалению, проблемы несовместимости.
Неясно только, почему бы в таком случае не сказать прямо - меня всё устраивает и переходить на что-то другое необходимости я не вижу.
Соответственно, сразу после установки оно готово к работе. Вы можете тут же, буквально нажатием одной клавиши, собирать и запускать программу. Никаких прописываний путей и прочей настройки — это цельный продукт, а не паззл, который надо сперва собрать из кусочков. Точно так же вы можете сразу отлаживать, расставляя точки останова в редакторе. И никогда не будет проблем из-за того, что убогий gdb опять как-то не подцепился редактором кода или чего-то не нашёл. Вы сразу можете вызвать справку кликом по любому идентификатору, и для этого ничего не потребуется настраивать.
По сравнению с этим, инфраструктура современных ЯП кажется до ужаса убогой и неудобной. Это конструктор «собери сам», причём даже после сборки такого удобства как в Delphi не будет — вечно хоть что-то да отвалится.
Да, всё )))правильно: раньше не знали, что программировать надо весело и куульно. И ещё плюс, как заметили выше, скорость сборки. Но есть )))нюанс. Это до середины нулевых у российского программиста стояло разнообразное ''современное'' ПО для любой области интересов. Потом пришли лицензии и началось... Например, embarcadero вовсе не плохой продукт, но посмотрите на его цену или цену других профессиональных инструментов. Поэтому везде и широко бесплатный пытон для учёбы и прототипов.
Согласен. Но заказчики не хотят delphi. Хотят C++, С#, Python, Haskel. Если хочеш зарабатывать, а не философствовать, придётся использовать эти языки. Раньше можно было пол деревянными досками накрывать, и было хорошо. Теперь ни кто деревянные полы не хочет, хотят ламинат. Не скажеш же заказчику, давайте я вам лучше из сосновых досок пол сделаю.
Вот только если состояние кирпичного дома оценить довольно легко, то чтобы оценить состояние каркасника потребуется весьма дорогостоящая экспертиза. Дом может выглядеть идеально, но на самом деле там все балки давно сгнили и вся конструкция вот-вот сложится…
Заказчик хочет ламинат. Ламинат - это инструмент? Нет, это результат работы. Заказчику не важно, каким инструментом ты будешь укладывать ламинат. Главное, чтоб он был уложен и уложен хорошо.
Вот оказывается не всё равно. Посмотрите заказы на фрилансе. Везде требования к языку, и даже к среде разработки.
Если делать студентикам задачки, то конечно они просят на конкретный язык. А если найти на фрилансе нормальный заказ на создание той или иной программы, то только единицы могут указать конкретную технологию. И то, в таком случае достаточно поинтересоваться "почему?" и можешь сам предложить технологию. заказчику будет не важно.
Мало того, весь этот инструментарий слишком сильно «зацеплен» за конкретную систему и потому очень хрупок. Перейдя допустим с Ubuntu на что-то ещё вы тоже потеряете все настройки и будете лепить всё заново.
Вот я, к примеру, из-за этого на Ubuntu 16.04 сидел до упора, пропустив 18.04, потому что был уверен, что при переходе всё сломается и надо будет настраивать заново. И да — когда на этом старье стало уже совершенно невозможно сидеть и пришлось переползать на 20.04, оно таки сломалось, и пришлось заново возиться с настройкой.
Причём каждый раз настройка — это не «вот потратил два вечера и дальше радуйся». О нет, потом в процессе работы то и дело натыкаешься на разные проблемы и шероховатости ещё не одну неделю. Всё время где-то что-то вылезает, и комфортность работы так себе, пока окончательно не отшлифуешь.
Разработка в Delphi достаточно быстра. Библиотеки для питона, которыми он так "славится" кто-то пишет. Т.е. такую же работу можно проделать и для Delphi. Т.е. опустим аргумент что "на питоне библиотеки для всего".
Далее, процесс разработки на Delphi не уступает питону. За исключением только что нужно освобождать память вручную.
Сравниваю с ним из-за коммента выше и по причине его бессмысленной популярности, из-за которой его пихают уже просто всюду, где он даже на минималках не вывозит.
У делфи масса преимуществ, о которых вам уже не один раз рассказывали. А в купе с возможностью быстрой разработки, быстрым внедрением собственных инструментов в среду и многочисленными инструментами среды из коробки, он является мощным инструментарием.
Не говоря уже о том, что язык развивается семимильными шагами.
А для начала необходимо указать, что имеется сейчас из того, чего нет в других языках.
1. Скорость и лёгкость разработки. Софт с GUI писать одно удовольствие.
2. Масса коробочных решений. Я написал софт для просмотра 3D панорам в 20 строк, в только что установленной среде.
3. LiveBindings и прочее
Ну а что нового... Во-первых я не знаю с какого момента для вас что-то будет новым. Если вы знакомы с делфи только по Delphi 7... То разговор будет долгим.
В среде есть штатные средства для создания 3D сцены. Как в юнити (почти). Исходника нет, т.к. он перерос в большой проект. Шаги следующие:
В дизайнере:
Добавляем на форму Viewport (сцена).
На сцену добавляем сферу.
На сферу помещаем материал (без освещения).
Приближаем камеру чтобы оказаться внутри сферы.
Кидаем компонент диалогового окна выбора файла
Добавляем кнопку
Выбираем сферу и добавляем её обработчик событий OnMouseMove, OnMouseDown, OnMouseUp
В коде:
OnMouseDown - флаг, что нажата мышь и запоминаем координаты мыши
OnMouseUp - снимаем флаг
OnMouseMove - 5-6 строк для поворота сферы в зависимости от смещения мыши
На нажатие кнопки выполняем диалоговое окно, выбранный файл загружаем в материал (3 строки)
Готово. Получаем кроссплатформенный софт для просмотра панорам. Можно собрать под винду, андроид и ios из коробки.
Это всё штатными средствами без каких-либо сторонних библиотек.
Есть и более быстрый способ. Есть репозиторий компонента, который вмещает в себя все вышеперечисленные шаги (+некоторые визуальные удобства, плавный скрол и т.д.).
С ним достаточно будет кинуть компонент на форму и добавить кнопку выбора панорамы. Т.е. 3 строки.
Могу скинуть ссылку на видео. Там проделанная работа за 3 дня. Все данные идут из сети. Софт собирается на андроид. Нацелен на планшеты. Но только в вк
https://vk.com/video58553419_456239669
Панорамы в видео, к слову, тоже сделаны в программе написанной на Delphi. Речь о программе для дизайна интерьера. И она написана как раз на Delphi 7. Т.е. работа со сценой и рендеринг всё сделано в одной программе.
Собственно я заморочился и добавил в гит. Код, который писался находится только в файле .pas (и то только то, что в процедурах внизу). Остальное автоматически генерируемые файлы.
https://github.com/HemulGM/Pano3D
Вот ролик, в котором показан пример исследования динамической системы «с нуля». Конечно, заметно, где код старый, а где поновее. Старая, графика, к сожалению, медленновата, но для многих применений её достаточно
Паскаль таки хорош в качестве языка «на всю жизнь»
Красивый ролик. Спасибо.
Весь этот код, запросто можно переделать на C/C++
Если говорить серьезно, то в своём приложении я практически не пользуюсь никакими сторонними компонентами, а у вас в процессе переделки это может и не получиться. В любом случае, интересно будет взглянуть на то, что у вас выйдет.
Не охота мне переделывать. Да и смысла нет. И времени тоже. Вроде даже специальные утилиты у Borland были, для миграции исходников между delphi и cpp builder
Правильно, для этого лучше брать языки из ML-семейства. Компиляторы и тому подобное на них очень приятно писатьКомпилятор выражений — только часть моего приложения, важная, но не едиинственная. Кроме того, нужно достаточно быстрое выполнение множества операций с плавающей точкой, действия с матрицами, возможность динамического выделения/освобождения памяти, работа с графикой. Для всего этого нужен был универсальный язык. Паскаль для этого подходил уже очень давно, и до сих пор он позволяет относительно просто дополнять систему, а также без проблем мигрировать на новые версии компиляторов и новые версии ОС
Тот же хаскель, по-вашему, этого не умеет?Понятия не имею. В 1991 я ни про какие Хаскели ничего не слышал, пользовался тем, что было просто и доступно. За 30 лет настоятельной необходимости в чем-то, кроме Паскаля, и не возникло. Для доказательства того, что Хаскель существенно лучше, нужно было бы написать на нём подобную систему, которая была бы существенно лучше в чем-то (быстрее, или работать на совсем уж разных ОС), да еще и чтобы она работала на всех промежуточных версиях Windows (и даже MS DOS)
Ну если всю жизнь заниматься одной программой, то, конечно, необходимости в других языках не возникнет. Они будут даже вредны — действительно, зачем переписывать уже работающее?Это приложение — развлечение для души, и я привожу его историю как пример, иллюстрирующий основную мысль публикации — почему автор до сих пор не отказался от Паскаля. Моё мнение — у автора есть для этого основания
Однако, чаще всего интересен вопрос о том, какую технологию выбирать для следующего проекта. Если бы вы сегодня эту систему делали с нуля, то вы бы тоже выбрали паскаль?Не могу ничего ответить, я не полиглот в отношении ЯП. Примерный аналог моего отношения к этому — это похоже на поддержание на ходу какого-нибудь древнего, но красивого автомобиля, при этом автомобиль должен быть сделан так, чтобы это позволить
и даже MS DOS
Где в 2021 году держат MS-DOS и с какой целью, интересно знать ;)
Где в 2021 году держат MS-DOS и с какой целью, интересно знать ;)Наверное, нигде не держат, я говорю о приложении, которое работало под MS DOS, работает под Win10 и является полезным до сих пор
Программа на Ассемблере под DOS тоже должна работать в Windows, why not. Если прямого доступа к железу не использовать.Интересно бы взглянуть на такую программу на Ассемблере, особенно без использования доступа к железу
Я недавно устроился в одну организацию. Есть программы под DOS. Причём, просто взять их и выкинуть не получится. Уж очень сильно на них завязано.
Выигрыш даст. Это больше заказов. Заказчики требуют чтобы было на C++. И ни на какие дельфя и паскали не согласны. Да и ещё за спиной у виска покрутят пальцем.
Весь этот код, запросто можно переделать на C/C++можно ответить только — ну, запросто переделайте и покажите, что получилось. Можно считать это резьбой по рисовому зёрнышку, на такое заказчиков, конечно, немного
Ну не всем же крупные проекты делать. А в мелких , тот же 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 с веб-фреймворками на других языках?
Почему именно веб-фреймворки? Это вообще не популярная вещь на Делфи. И я уже сказал, я не использовал веб-фреймворки (только для фронта). Я не знаю где есть тесты.
Потому что вы сказали о производительности языка без указания сценариев, сказав, что остальные языки проигрывают. Вот я и заинтересовался, стоит ли рассматривать так расхваливаемый вами Дельфи для моих задач.
Пока выходит, что бесполезно.
Как связана производительность языка и наличие в нём конкретных фреймворков? Язык обладает высокой производительностью. Высокая производительность ни как не гарантирует в языке наличие по умолчанию веб-фреймворка.
Возьми делфи, веб-фреймворк, протестируй если тебе интересно. Я знаю его производительность в других задачах.
Как связана производительность языка и наличие в нём конкретных фреймворков? Язык обладает высокой производительностью.
Я не очень понимаю, что такое "производительность языка". У меня решения, написанные на одном и том же языке, могут отличаться по производительности на порядки. Так что меня интересует производительность конкретного решения на конкретной задаче. Вот TechEmpower запарились и сделали такое сравнение для типовых веб-фреймворков.
А "производительность языка" — это что-то абстрактное, что я никогда в своих задачах не увижу.
Возьми делфи, веб-фреймворк, протестируй если тебе интересно.
Не, мне не интересно тратить свое время на тестирование производительности решения на языке, который может быть даст мне выигрыш в производительности, но ни в чем остальном (из того, что я видел, конечно) не выигрывает у подходов, которыми я сейчас пользуюсь.
В Делфи совсем не давно появилась возможность собирать код под Линукс. По причине того, что в сервер в 80% - это сервер на Линукс, а компиляции под линукс у Делфи не было - нет и большого количестве веб-фреймворков. Это сейчас есть RESTfull и прочие фреймворки, работа которых возможна в Docker.
Именно по этой причине нет того, что вы от меня требуете и именно по этому Делфи вам на данный момент не подходит.
Высокая скорость работы обусловлена тем, что язык компилируемый, строго типизированный и позволяет передавать параметры функций на стеке. Человек, с которым я общаюсь требует конкретное тестирование как веб-сервиса. Если вам интересны тесты скорости - погуглите. В наше время это не так и сложно.
Высокая скорость работы обусловлена тем, что язык компилируемый, строго типизированный и позволяет передавать параметры функций на стеке.
Дельфи тут не одинок совершенно, не повод считать его самым быстрым, или даже "только он и cpp".
А, главное, в контексте реальных задач это часто не имеет значения (смотрите результаты тестов выше).
Если вам интересны тесты скорости — погуглите. В наше время это не так и сложно.
Так я погуглил, ничего не нашел.
Производительность, да. И не только. Он во всём превосходит все новомодноые языки тип питона. Вот только заказчикам этого не обьяснить. Им нужен питон и точка. Никаких других доводов они и слышать не хотят. Спорить с ними бесполезно. Лучше под них приспособится, и зарабатывать деньги. Чем быть гордым но нищим разработчиком Delphi.
Если кто-то попросит крупный софт с GUI на питон я посмотрю, как ты будешь это делать
Он во всём превосходит все новомодноые языки тип питона.
Вот прямо вот во всем?
А C# вы тоже считаете новомодным языком, на всякий случай?
Вот только заказчикам этого не обьяснить. Им нужен питон и точка.
Ну, я могу их понять: у них есть набор требований по поддержке, куда может быть включен конкретный язык. Мало же найти того, кто софт разработает, надо еще иметь возможность найти кого-то другого, кто этот софт будет поддерживать.
Ну не запросто. Времени уйдёт немало и непонятно на что.
Правда я в своё время разрабатывал автоматический транслятор в Си(без плюсов) для микроконтроллеров. Но там код требует иногда правки вручную, а чтобы 100% автоматически делалось, это требуется слишком много времени, да и мало кому нужно.
А на PascalAbc.net не пробовали откомпилировать?
Ну с 2018 года там много глюк исправили. И уже и тогда эти глюки касались тех вещей, которые не были в Турбо Паскале. Его сейчас активно используют в школах, так что если бы были серьёзные проблемы с переносом программ, то это было бы широко известно. Поэтому если вы активно не собираетесь использовать "новые фичи", то всё должно работать.
Немного не в тему. У самого установлен Delphi 7, но честно забыл когда последний раз запускал. Буквально на днях вышла новая бесплатная версия: https://www.embarcadero.com/ru/products/delphi/starter
Уж очень быстро привыкаешь к хорошему и новым плюшкам.
Приходилось переносить свои старые проекты с 7-ки на 10.2 в среднем 1-2 дня работы (правда проекты не особо крупные).
ps О delphi 7 самые теплые воспоминания (студенчество).
с 7-ки на 10.2 в среднем 1-2 дня работы
Сколько багов добавлял перенос?
Сейчас точно не вспомню, но минимум. Сторонних компонентов практически не было, GLScene попутно обновил до последней версии и все заработало.
"минимум" больше нуля? И один баг поймать или увидеть, что багов нет, много времени уходит.
Багами назвать трудно, в основном были несоответствия типов и пришлось немного код переписать.
Попробуйте впихнуть в значимое имя фразу: загрузить из архивного файла, записи для товарных вагонов, расшифровать их, пустые вагоны добавить в таблицу свободных вагонов.
Забавно. У меня коллега тоже долго доказывал, что «в нормально читаемом коде комментарии не нужны». Ровно до тех пор, пока не пришлось писать ПО для микроконтроллера в специфическом устройстве. Ибо код, плотно завязанный на железо, получался абсолютно непонятным без комментариев, описывающих специфику этого самого железа. Так что когда кто-то говорит, что «в нормально читаемом коде комментарии не нужны» — это значит, что человек никогда не писал ПО для взаимодействия с чем-то аппаратным.
На данный момент Lazarus упомянут уже дважды, но так? что всё равно приходится спрашивать живого человека сидящего на Delphi 7 - ну почему не Lazarus?
А он полностью совместим с Delphi 7? Т.е. любая прога на нем скомпилируется? А баги могут возникнуть при переносе?
Читаю вики:
однако полной совместимости с Delphi нет
Понятия не имею, не пробовал дальше ЗдраМир. Рядом задал вопрос про Embarcadero, так оно выглядит неплохо, воспоминания детства освежает, но сайт по части как скачать и установить бестолковый крайне. А суть проста - инсталятор один, ориентируется по ключу, ключ приходит на почту.
Если вы используете только стандартные оконные компоненты (заметьте что речь идет не о классах вроде TList, а именно о таких компонентах вроде TEdit, TMemo), и не используете специфичный синтаксис языка Delphi (а в Delphi 7 такого сахара отличного от стандарта синтаксиса FreePascal практически нет), то код будет полностью совместимым.
Если же вы используете манипуляцию со стоками (речь идет о кириллице в Ansi), то вместо String надо будет просто указать AnsiString, и тогда тоже никаких проблем не возникнет.
Более того вы сможете скомпилировать приложение под 64-бита и даже на linux, а при желании и на MaсOS.
Пляски начинаются только если вы используете что-то выходящее за вышеописанное, но и тут не проблема, есть встроенный инструмент преобразования кода Delphi в код Lazarus, вот тут вроде неплохо описан этот процесс:
https://delphi-devs.ru/index.php/portirovanie-proekta-s-lazarus-na-delphi.html
Очень может быть, я его запустил, заподозрил именно это, и убрал.
А Embarcadero Delphi Community Edition?
Глюков не так много. Потом, если их знаеш, уже не возникает вопросов, просто обходиш их. Зато главное преимущество lazarus он GNU.
Разная степень готовности компонентов -основной глюк.Я с одного сайта взял пример Солнышка-в винде все работает,в линуксе нечего не выводит.При этом кроссплатформенные компоненты и ошибок компиляции нет.....
Я не использую компоненты. Только минимальный набор стандартных. Form, там button, memo, label, bitmap. Они работают без глюков. Мне всякие красивости и украшательства не нужны. Вот с базами там беда. То что отлично работало в delphi, иногда совсем не работает в lazarus. Приходится всякие подпорки ставить.
Глюки версия от версии исправляются, особенно если люди о них сообщают сообществу лазаруса, или сами пишут "патч" и опять таки предлагают его внести сообществу лазаруса.
А вот что мне действительно не хватает в нем, так это такого же мощного отладчика, который был в Delphi.
Его как-то почти не развивают, и если код по нему смотреть еще вполне можно, и текущие данные в переменных, то в сложном многоуровневом дереве структур данных он уже сильно уступает отладчику в Delphi.
(например данные вроде:
variable: record a:array of record sa: array of record ssa:array of class; end; end;end;
То проверяя variable в отладчике Lazarus будет сложно посмотреть что же все таки хранится в данный момент в variable.sa[0].ssa[0].class)
Мои научные интересы в основном принадлежат области математической (или, как еще называют — компьютерной) химии. Это применение теории графов к фундаментальным и прикладным задачам органической химии
К сожалению D7 не способен выжать максимальную производительность из современного железа. Всё же лучше смотреть на julia,python,r они больше подходят для решения практических задач, не погружаясь в детали железа. Современные процессоры это примерно 0.4TFlops, но это с использованием векторных инструкций и много поточности и других «но», а D7 способн только FPU использовать, а это единицы GFlops. Если использовать cuda, opencl то можно получить до 30ТFlops на одну видеокарту в домашних условиях.
Но, конечно, «устарелость» Delphi-7 дает себя знать
Используйте U++ там всё даже проще чем в delphi, но при этом это обычный c++ и все библиотеки подключаются и оптимизировать можно под современное железо.
ps: delphi7 использует для справки файлы .hlp и начиная с windows7 их из системы выпилили и вместо winhlp.exe лежит заглушка. Если этот файл заменить на файл от winxp то справка вновь будет работать.
Как человек, прямо сейчас работающий на легаси средствах разработки - скажу, что проблема наступает, когда возникает необходимость в одном из трёх действий:
1) Присоединить к проекту другого программиста, или полностью передать проект ему.
Выглядит особенно грустно. Большинство программистов, увидев в 2021 году хотя бы 10-летнее легаси, начинает очень быстро пытаться или отгрести, или переписать код на современные рельсы, вынуждая Вас апгрейдиться. Я вот тоже недавно видел код на C++, где обработку ошибок кто-то реализовал на (привычных ему) longjmp-ах. Я вообще не знал, что на C++ так можно.
2) Портировать проект на ОС, где средства разработки и/или собранные ими программы живут уже с трудом.
Со временем появляется ОС, где старые наработки не живут, или живут плохо. Хотя недавно я открывал свою старую игрушку на Visual Basic 6 - и хех, под Win10 она до сих пор работает.
А вот часть библиотек, используемых в другом проекте, уже работают даже под Win7 некорректно.
3) Добавить в проект поддержку новой библиотеки, которая не имеет точек входа, запросто доступных для Ваших средств разработки.
Печальная правда. Поддержка старых версий и стандартов отваливается, документация исчезает, знания рассеиваются. Для любого следующего действия приходится заниматься прикладной палеонтологией.
Пришол в организацию, где работают с программами написанными на клиппере. Если windows x64, запустить их там большие проблемы. Что то исправлять приходится очень долго. Основная часть веремени уходит на поиск того, где это. Потом долго думаеш как оно работает. А исправить 3 минуты.
>Если windows x64,
А что там с проектом http://www.harbour-project.org/ ,не слежу и не занимаюсь клиппером,просто интересно.Я давно слышал что там портировали на linux и даже у народа есть интересные проекты.
Мне кажется новичкам и сейчас актуально писать начинать на паскале, тот который ABS вполне норм работает на актуальной винде. Достаточно просто хэлоуворды писать и алгоритмизацию учить и при этом строгая типизация.
Если новичок планирует получать какие то ₽₽₽ или $$$ - неплохо посмотреть на вакансии и зарплаты.
Вот, что-что, а PascalABC вообще к паскалю только внешней схожестью относиться, работает совершенно иначе, вдобавок имеет намешку от .NET, и совершенно не годиться для написания чего-то серьезного.
А еще много чего на нем работает не так как должно. Приходилось как-то помогать писать студенческое приложение для решения простенькой задачи, написал за минут 10, проверел в нормальной среде (для Lazarus и Delphi этот код работал без проблем, более того этот код работал бы и на TurboPascal), но как выяснилось этот код был совершенно неработоспособен в PascalABC, пришлось ставить это чудо и смотреть, что же ему не нравилось, после целого дня возни и экспериментов, выяснилось, что он иначе строит структуру строк, и если дополнительно не приклеивать некоторые символы в конце, то стандартные методы WRITELN начинали падать, как и странно работал READLN, захватывая в строку лишние символы. Возможно с того времени это уже исправили, но все равно многие вещи которым обучают на нем, работают только на нем.
Лучше уж на Lazarus, так же бесплатно и современно, и без лишних примесей, и кроссплатформенно, и вполне можно писать что-то серьезное, начиная от простых десктопных программ, полноценных игр, и заканчивая многопроцессорными комплексными приложениями, или приложениями с высокой нагрузкой и сложной структурой данных.
И все это так же из коробки после установки.
При желании даже CGI-приложения можно легко написать, или мобильное приложение создать (хотя это немного сложнее, так как требует отдельной возни с компилятором).
В Delphi обычно несовместимость при переходе на более новые версии из-за компонентов. Однако для многих из них всё-таки аналоги есть.
Я по опыту помню переход в 7 на 2006 запомнился тем, что надо было взять новый компонент СPort. В Delphi 2010 появился Юникод + опять менять СPort. В XE2 , опять менять СPort. При переходе на XE7 и 10 и вспомнить-то особо нечего. В основном просто старый код работал в новой среде.
А обновлять надо, т.к. ещё в XE7 программы на Андройд работают косорыло, тот же USB у меня так и не заработал, а на 10 всё нормально. Так что кросплатформенный код сейчас требует обновления. Если только для Windows , то да, можно десятилетия ничего не менять.
Не ожидал, что будет столько отзывов!
Всем спасибо!
Скажу: нтересно, если Паскаль возродится, а мне возразят, что не умирал ;)
Шикарная статья.Меня самого в принципе устраивал D7 до недавнего времени.
Только у него очень медленная сборка больших,да и средних проектов тоже.
А когда я полез смотреть алгоритмы обработки видео/изображений то тут пришлось переходить на новую(старую XE4) ради вменяемой многопоточности.
Да тоже простейшее распознавание образов на D7 к сожалению не проверить именно на "скорость" отработки алгоритмов в параллельном исполнении.
А так использую постоянно,самая шустрая среда для быстрых тестов.
И да, паскаль не умирал :)
Спасибо.
устраивал D7 до недавнего времени.
Только у него очень медленная сборка больших, да и средних проектов тоже.
[...]
Да тоже простейшее распознавание образов на D7 к сожалению не проверить именно на "скорость"
М.б. проекты запредельного объема, которые в любой IDE будут тормозить. Модульность, COM и т.д. в помощь. Я использовал распознавание на OpenCV в не самом простом проекте. Компилировалось очень быстро — не мерял доли секунды.
Интересно, что интерпретатор Pascal P5 на D7 быстро работает.
Действительно:
И да, паскаль не умирал :)
Про многопоточность. В начале 2000х участвовал в международном конкурсе-марафоне Intel, на многопоточность. Занимал 5 место используя D7. Мой код по скорости не уступал коду на C++, но за использование Intel Threading Building Blocks начисляли доп. очки. Были участники и со своим компилятором C++.
Занимал 5 место используя D7.
Знаю что там нет большого преимущества у С++.
Я имел в виду удобную прикладную многопоточность(когда отдал всё на обработку в TreadPool и быстро посмотрел результат) а в 7 Дельфи нужно посидеть и написать свои классы и обёртки для системных потоков(если не имеется подобных наработок заранее).
Я не знаю что за трабл такой но сборка 24000 строк кода в D7 у меня занимала несколько минут.Очень медленно именно GDIOBJ.pas и GDIPAPI...
К слову в новой IDE(XE4) это за 0,3 сек происходит.
Я не вникал почему так,возможно экономия памяти,а возможно что компилятор однопоточный.
Диск SSD 1Tb Samsung Evo Plus один из самых быстрых NVME третьего поколения PCI_E.Оперативной памяти больше чем нужно (128Гб).Процессор 12 ядер/24 потока хватает для любых задач,хоть линукс собрать из исходников.
Вот ради теста пересобрал опять,время на скриншоте.
https://ibb.co/N9QMd9v
Я использовал распознавание на OpenCV
У меня не получилось подключить CV...Хотя пробовал раза три.
В итоге переписал нужные функции оттуда полностью на паскале,например поиск границ,поиск шаблона,фильтрацию MeanShift,кучу других фильтров..K-means например.сейчас пишу сегментацию разрастанием регионов.Свой код иметь удобнее,полный контроль и понимание происходящего :)
Кроме уже упомянутой OpenCV использованы библиотеки Delphi-OpenCV (Laentir Valetov, Mikhail Grigorev)
Свой код, безусловно, удобен, но это лишнее время и силы.
Спасибо.
Но уже не буду :) У меня есть почти все основные функции.
Я начал так сказать личный челлендж по "переписыванию" OpenCV на Паскаль, только с паскалевскими типами данных .завершено ~15%.Есть начало реализации SIFT/SURF/FAST/ORB(пока читаю документы) .
Даже не знаю во что это в итоге выльется...Разработчики Делфи давно обещали поддержку AVX2,но так и не сделали даже в новых версиях,аргументируя что есть более важные задачи у них.А ведь это основа обработки больших массивов данных,например в видео потоке или распознавании....В любом случае весь мой код пока он маленький работает и на D5,D7 и на XE4 и на Rio 10.4.2.
В CV много не сделано, и Вам хватит работы на много лет. Так совпадение с шаблоном-картинкой зависит от ориентации, и мне пришлось использовать 8 тестов на совпадение. Была переписка с разработчиками — они честно признали, что недоработка.
Разработчики Делфи давно обещали поддержку AVX2, но так и не сделали
Интересно, а асм-заплатки тут будут работать или только inline?
В CV много не сделано, и Вам хватит работы на много лет Так совпадение с шаблоном-картинкой зависит от ориентации
Уже три года пишу :)
В опенЦв может и зависит :) У меня нет.
Я же не тупо копирую,а пишу СВОЙ код исходя из потребностей,но на примере кода OpenCV.
Про инлайн столько споров...Раньше он вызывал рост размера приложения.
А про асм вроде вставки в процедуры/функции уже давно запретили.
Осталась возможность писать лишь целиком функцию на ассемблере.
Желаю успехов!
Будет очень интересно опробовать Ваш код — сообщите, пожалуйста, когда будет готов.
Про асм запретили — это одна из причин, что не использую новые версии Делфи. У меня много старого кода, где асм.
P. S. Вот для других платформ asm не поддерживается.
Почему я продолжаю использовать устаревшие виртовский Pascal и Delphi-7