(Модель античного святилища Аполлона в Дельфах)
Почему я продолжаю использовать устаревшие виртовский Pascal и Delphi-7?
Этот вопрос мне часто задают мои коллеги, сослуживцы по работе и здесь на Хабре. Решил ответить сразу всем в этой заметке.
Мои научные интересы в основном принадлежат области математической (или, как еще называют — компьютерной) химии. Это применение теории графов к фундаментальным и прикладным задачам органической химии (немного подробнее см.).
Для решения этих задач я применяю уже известные алгоритмы, иногда их модифицирую, а иногда делаю новые. Решение научной задачи обычно предполагает последующую публикацию в рецензируемом научном издании. Еще до начала работ стоит подумать: в каком виде я собираюсь описать новый алгоритм?
В настоящее время можно выделить четыре распространенных способа такого описания.
1. Описание на естественном языке, пожалуй, самый легкий способ. Это древнейший способ. Евклид (около 300 года до н.э.) и Эратосфен (276 год до н. э.) его использовали. Переводы и пересказы описаний их знаменитых алгоритмов широко применяются по сей день. Но и новейшие алгоритмы часто описывают этим способом. Правда, математических формул в таких описаниях стало сильно больше, по сравнению с древними описаниями. Основной недостаток этого способа — многозначность многих слов естественных языков. Поэтому существует не малый риск, что автора поймут неоднозначно. И т.о. не смогут воспроизвести его алгоритм. А воспроизводимость — одно из основных условий научного метода.
2. Описание на псевдокоде. Тоже очень популярный способ. Тут можно выделить два подхода:
2.1. Изобретение оригинального псевдокода. Так Дональд Кнут для своей знаменитой монографии «Искусство программирования для ЭВМ» специально придумал компьютер MIX и ассемблер MIXAL. Тут явный недостаток — высокий порог входа. Для первого издания этой монографии в прошлом веке, такой подход, возможно, был оправдан. К настоящему времени создано много эмуляторов MIX, позволяющих увидеть, как работают коды из книги. Но для не очень большой статьи изобретение оригинального языка не представляется оправданным.
2.2. Использование для псевдокода упрощенной версии существующего ЯП. Про этот подход будет сказано ниже.
3. Описание на ЯП. По сути, это уже не описание алгоритма, а его реализация в виде программы. Здесь недостатки очевидны. Если читатель не знаком с применяемым ЯП, то ему может быть сложно (от слова «совсем») понять суть алгоритма. Детализированная публикация программы может вызвать сложности в бумажном издании — недостаток места. А места обычно нужно больше, чем в первых двух способах. И чтение всей программы целиком, потребует больше времени и внимания.
4. Описание с помощью блок-схемы. Этот способ уже довольно давно стал популярным. Еще Эдсгер Дейкстра его использовал в «Заметках по структурному программированию».
Для описаний небольших алгоритмов блок-схемы, безусловно, очень привлекательны своей наглядностью. Но, к сожалению, с ростом числа ветвлений и циклов блок-схема разрастается и повышается трудность восприятия. В случае бумажного представления формат бумаги может оказаться мал для блок-схемы. В связи с этим нужно упомянуть визуальный ЯП ДРАКОН, в котором предприняты меры по преодолению означенных неудобств. Однако применение специального ЯП может вернуть нас к способу 3.
Исходя из сказанного, я выбрал для себя способ 2.2. На мой взгляд, одним из наиболее подходящих для псевдокода является виртовский Pascal. Его, похоже, знают и помнят все программисты, а кто не знает — стесняется в этом признаться. Pascal-образный (Pascal-like) псевдокод интуитивно понятен (всем кто знаком, хотя с одним универсальным ЯП) и обычно хорошо структурирован, если нарочно не засорять его чем-то громоздким, и, конечно же, не использовать пресловутый goto. Для такого псевдокода доступны чекеры, и не только спелл-чекеры для правки комментариев, но и код-чекеры для кода. В роли последних выступают компиляторы и интерпретаторы Pascal. Например, очень удобен Dr Pascal. Превратить текст на псевдокоде в съедобный для транслятора обычно труда не составляет. Мне представляется очень важным, что Pascal — жестко типизированный ЯП, последовательно реализующий принципы защитного программирования. – На этапах разработки и проверки алгоритма, средства минимизации багов очень важны. А вот трюки, типа неявных преобразований бывают вредными.
Два слова про комментарии: считаю, что комментировать нужно уже в описании алгоритма. Причем комментировать достаточно подробно – это поможет поиску ошибок, и при написании статьи. Бывают трудные задачи, которые непонятно, как решать. Тогда я начинаю со способа 1. Записываю идеи решения в текстовой файл. Далее пытаюсь детализировать эти записи, выделить подзадачи и перейти к способу 2.2. Аналогично поступаю, если есть ТЗ. Правлю копию ТЗ с целью перейти к способу 2.2. Фразы от способа 1 оформляю комментариями. Такой прием помогает выбрать значимые имена. Если работа не на заказ, то сам пишу себе ТЗ. Описание алгоритма нужно и в случае, если не собираетесь его публиковать. Проходит время, и вы с удивлением смотрите на исходный код, реализующий алгоритм, который вам был когда-то совершенно понятен.
Еще про значимые имена – они очень важны, но комментарии не отменяют. Попробуйте впихнуть в значимое имя фразу: загрузить из архивного файла, записи для товарных вагонов, расшифровать их, пустые вагоны добавить в таблицу свободных вагонов. Получите довольно длинное имя, которое либо каждый раз безошибочно набирать, либо копировать, что может потребовать частые промотки текста. Код с такими много раз повторяющимися именами будет объемнее, чем код с единственным комментарием.
Следующим шагом после написания и описания нового алгоритма может быть его реализация и испытания полученной программы. Иногда это оправдано до доказательства корректности и теоретических оценок эффективности. — Зачем оценивать алгоритм, который врет. Для реализации использую IDE Delphi-7. Здесь у меня личная историческая причина. К примеру, если мой алгоритм на графах, то для испытаний нужно будет грузить графы. Их быстрее набирать в виде списка смежности, а для алгоритма нужна матрица смежности. Ну не писать же мне для каждого алгоритма процедуры трансляции списка в матрицу? — Понятно, что возьму эти процедуры из своего старого кода. Но почему Delphi-7, а не более новое? — К сожалению, проблемы несовместимости. Ну, а зачем с виртовского Pascal переносить на ОО Pascal Delphi? — Он ОО; зачастую даже для испытаний полезен или, даже, нужен GUI; иногда нужно испытать параллельный алгоритм и т. д. Использую не только свои старые процедуры I/O, но и, к примеру, реализацию поиска кратчайшего пути в графе, сортировку и т.д.
Но, конечно, «устарелость» Delphi-7 дает себя знать. OpenCV удалось применить и надписи в GUI Юникодом сделать (иначе под Windows 10 у моего любезного тестера не читались), а вот для CUDA пришлось переходить на C++. Отмечу, что когда программирую, то offline под Windows ХР SP 3 (с отсутствием Юникода в Delphi-7 проблем не возникает), а для online гружу другую ОС.
Говоря про испытания алгоритма, нужно отметить, что удачная работа программы — это хорошо, но, зачастую, не достаточно. Обычно нужно математически строгое доказательство.
Если лень или не удается строго доказать (самому или с чьей-то помощью), то иногда автор алгоритма объявляет его эвристическим. В общем, это может быть не страшно плохо. Есть задачи, для которых никто не нашел строгого решения. Есть такие, где ошибки не катастрофичны, например, в играх. Но есть и другие задачи. Например, поиск изоморфизма двух графов. Это известная открытая проблема, где нужно доказать, что эту задачу можно решить за полиномиальное время от числа вершин графа или, что такого решения быть не может. Притом, что открытой является и проблема P ?= NP. Предложено много эвристических алгоритмов поиска изоморфизма графов, только они никому не нужны.
После успешной проверки можно причесать программу. Сделать GUI удобным, подумать об оптимизации.
Здесь я написал про свой подход. Он, конечно, не единственный. Некоторые математики, не умея программировать и не зная ни одного ЯП, предлагают прекрасные алгоритмы для самых разных задач. Для описания алгоритма используют обычно способ 1 — естественный язык с большим количеством математических формул. Я же придерживаюсь взгляда, что CS — экспериментальная наука, разделяя мнения Аллена Ньюэлла и Герберта А. Саймона (Newell, Allen; Simon, H. A. (1976), «Computer Science as Empirical Inquiry: Symbols and Search» (1975 ACM Turing Award Lecture), Communications of the ACM, 19).
Комментарии (334)
eklementev
22.07.2021 00:44+9Остаётся отдать должное стойкости людей, отказывающихся принять прогресс.
И я не про текущие технологии и реализации, а про то, как они будут искать тех, кто примет и продолжит.
agmt
22.07.2021 06:11Вероятно, это особенность нервной системы. Кому-то больно использовать старые стандарты/компиляторы, а кто-то из версии в версию Boost тащит поддержку pre-C++11.
Боль наступает, если по недосмотру они попадают в 1 проект (я такого не встречал).
kalapanga
22.07.2021 02:37+2Подозреваю, что автор в своё время набрал кучу чужих библиотек без исходников, которые сейчас авторами заброшены и под новыми версиями Delphi не работают. Это единственная причина сидеть на старье.
fraks
22.07.2021 04:12+2Чужие библиотеки с исходниками, и даже купленные с исходниками - совершенно не гарантируют что они не будут заброшены авторами, и что вообще автора можно будет найти. И самостоятельно мигрировать чужую библиотеку на новую версию Delphi - тоже тот еще квест. На этом фоне радуют FastReport - многие годы никуда не деваются, а последняя версия все еще работает и на Delphi 7 и на Lazarus.
agmt
22.07.2021 06:14-2Тут возникает вопрос: а надо ли так держаться за язык, компиляторы которого несовместимы, а новые версии обратно-несовместимы?
Error1024
22.07.2021 06:26+2Обратная совместимость в языке — одна из лучших. Однако некоторые авторы библиотек намертво привязывались к определенным недокументированным вещам, конкретному поведению конкретных версий библиотек, ОС, и т.д. — в целом как и везде в нативном мире.
fraks
22.07.2021 06:30А извините, у каких языков компиляторы полностью совместимы?
И полностью обратно совместимы?
inv2004
22.07.2021 07:35-3плюсы близко к этому
remzalp
22.07.2021 09:20+1Как-то решал в Gentoo квест - собрать старый компилятор еще более старым компилятором, чтобы собранный компилятор откомпилировал нужный код.
Если кратко - хоть и близко, но еще нет абсолютной обратной совместимости.
0xd34df00d
22.07.2021 10:07+3Плюсы не близки к этому ни де-юре, ни тем более де-факто. Поэтому, например, в одной компании, где я работал, миграция компилятора с GCC 4.2, кажется, на 4.7 заняла шесть лет (вместе с включением
-std=c++0x), а 4.7 на 5.3 — ещё два года.
mk2
22.07.2021 12:24+1>с GCC 4.2, кажется, на 4.7
Это там бинарную совместимость сломали? Тогда совершенно неудивительно.0xd34df00d
22.07.2021 20:04Там дело было не в бинарной совместимости (у компании был серьёзный NIH-синдром и все исходники доступны), а в том, что и компилятор, и стандарт стали чуть строже.
Аналогичные проблемы у меня были и в другой компании, где я пытался заставить код, написанный под gcc 6, собраться под gcc 9 и не помню каким clang, но там я в одно лицо управился всего за месяц, ибо кода там было всего-то 50-100 kloc.
Олсо, к слову о бинарной совместимости, её сломали и в C++17 (
noexceptстал частью mangled-имени), и в C++20 (из-за концептов и известной темы сrequires true).
third112 Автор
22.07.2021 11:04Delphi 5, Delphi 6, Delphi 7 — полностью совместимы. Без проблем пеходил не меняя кода. Даже асм заплатки.
fraks
22.07.2021 11:56Я мигрировал так: Delphi 1->2->3->5->7.
Каждая миграция вызвана тем что в новой версии есть то чего мне в старой не хватает. Соответственно, раз в новой есть а в старой не было - полной совместимости нет. Остановился на D7 потому что этой версии мне достаточно и нет причин тратить ресурсы на более новую.
Каждая миграция не обходилась без проблем. И это при том что все компоненты с исходниками. Хорошо что написано много своих велосипедов - их мигрировать проще всего.
Сейчас использую все это под Win10. Есть некоторые шероховатости с юникодом, но в целом - все хорошо. Пример шероховатостей - системный символ рубля стал юникодным :) Т.к. мы работаем исключительно в рублях - просто везде убрал вывод денежной единицы. При желании можно было подменить на неюникодный, но смысла нету.
Прикупил TurboDelphi но так на нее и не перешел.
major-general_Kusanagi
22.07.2021 12:33+2В Delphi 8 — сломали совместимость, что привело к смерти Delphi. :(
raTaHoa
22.07.2021 20:55Delphi 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.
Что занимает несколько минут работы, учитывая что в среде есть поиск по проекту с автозаметой.
unsignedchar
22.07.2021 10:03Тут возникает вопрос: а надо ли так держаться за язык, компиляторы которого несовместимы, а новые версии обратно-несовместимы?
python2/3, C++, ну их всех, ага ;)
0xd34df00d
22.07.2021 10:04+2Если оно чинится в полуавтоматическом режиме, а все несовместимости вываливаются на этапе компиляции, то вполне можно держаться.
Superdry
22.07.2021 03:06-2Попробуйте python 3 + typing модуль. Код будет не хуже.
quwy
22.07.2021 20:52Интерпретатор вместо нэйтива для научных числодробилок? Серьезно?
khajiit
22.07.2021 21:05+5"Дробить"-то все равно будет numpy или что-то похожее. Возможно, даже через CUDA или OpenCL.
quwy
22.07.2021 21:12Нафига нужен питон, если всю работу за него делают языки, на которых написаны библиотеки и расширения?
khajiit
22.07.2021 23:23+4Потому что код на питоне — это способ по-быстрому связать разные либы в одном пайплайне. Как трубопровод в шелле.
Для остального он слишком тормозной.
DirectoriX
23.07.2021 12:59+4Мы тоже несколько месяцев назад так подумали и решили вместо Python-версии Tensorflow использовать С++-версию (на кой нам лишние обёртки?). Потребление памяти снизилось заметно, время работы — на жалкие проценты в пределах погрешности. Зато код распух в десятки раз.
В итоге плюнули и вернулись обратно на Python.
libroten
22.07.2021 05:23+4Попробуйте впихнуть в значимое имя фразу: загрузить из архивного файла, записи для товарных вагонов, расшифровать их, пустые вагоны добавить в таблицу свободных вагонов.
Так даже впихивать не надо.
Тут явно напрашивается разбить это все на функции, которые можно назвать одним-двумя-тремя словами.
Тогда код будет чуточку более самодокументируемым и чуть менее нуждающимся в комментариях :)
third112 Автор
22.07.2021 10:33-1Разбить на ф-ции проще простого. И код будет имнть кучу повторяющихся фрагментов:
загрузитьИзАрхивногоФайла(записиДляТоварныхВагонов); расшифровать; пустыеВагоныДобавить (таблицаСвободныхВагонов); Если фрагмент повторяется многократно, то его обычно прячут в ф-цию. Получим: загрузитьИзАрхивногоФайлаРасшифроватьПустыеВагоныДобавить(записиДляТоварныхВагонов, таблицаСвободныхВагонов);
lair
22.07.2021 10:42+4Будем честными, оба варианта выглядят странно, потому что не очень понятно, где же чья ответственность. У вас правда одна функция возвращает два слабо связанных набора данных (товарные вагоны и свободные вагоны)?
InterceptorTSK
22.07.2021 11:27+3Так давно никто не делает. Всё это решает ооп, где всё сильно упрощается [впрочем, и усложняется тоже].
Если ооп, то у вас всё это разлетится на кучу объектов, где совершенно не будет монструозных длинных имён.
Объект Файл, у него функция Файл.Загрузить();
Абстрактные объекты записей будут, от них наследованы ваши записи.
У вас там выше не товарные вагоны должны добавляться, а записи.
СписокЗаписей.Добавить(Запись); А то что под записью это запись товарного вагона - за это и отвечает ооп. И не важно что у вас там - товарные вагоны или не товарные, буратины или боенги с кирпичами, ооп разгребёт всё само, на то оно и ооп.
И т.д. и т.п.
Если фрагмент повторяется многократно - то зовут вменяемого программиста, который накорячит архитектуру под определённый язык и сообразит библиотеку базовых типов под это всё дело, а так же основные базовые действия с типами, их преобразования и т.д. Обычно оно называется фреймворком.
Не использование ооп там где это действительно может помочь - глупейшая ошибка. Впрочем, использование ооп там где оно нафиг не нужно и можно обойтись без ооп - ещё более глупая ошибка.
Однако же т.к. автор - учоный [вроде бы], то и спрашивать с него нечего. Понять, простить.
Разбить на функции проще простого можно тогда и только тогда, когда нет абстракций. А у учоных их нет) Учоный мир живёт на композициях, потому то оно и не интересно.
Специально для учоного:
Понимание - это сравнение. Но механизмов сравнения абстракций у учоного мира не существует. Отсюда все беды. И эти беды у программистов отсутствуют.
Как обычно пример на пальцах. У меня знакомый физик есть, и он упоротый как любой учоный. Я ему так и смог объяснить что Солнце - это не звезда, а имя собственное. Вот хоть тресни - не получается. А ведь человек публикуется в очень крутых местах. А уж собрать базовую систему типов астрономических объектов для учоного - это вообще нерешаемая задачька по определению.
Причём понятное дело что Солнце как имя собственное должно быть приляпано как интерфейс к абстракции астрономического объекта, смех в том что в этот интерфейс ещё и абстракции народности надо забрасывать, ибо всё у всех называется по-разному.
И т.д. и т.п.
third112 Автор
22.07.2021 13:02+1Я высупал в защиту ООП. И исполюзую ООП. Но при разработке нового алгоритма ООП не всегда удобно. И для описания м.б. не очень удобно.
И да, я "учоный", но многие мои проги к науке отношения не имеют.
0xd34df00d
22.07.2021 20:20+1Зачем тут вообще ООП, когда это решается системой модулей?
import MyFavouriteFileLib.Data.File as File -- ... foo = File.load "filepath"Ух, правы были некоторые фанаты окамля, когда говорили, что в подавляющем большинстве случаев ООП — это такие модули для тех, у кого в языке адекватную систему модулей не завезли.
InterceptorTSK
23.07.2021 15:33-1"Зачем тут вообще ООП"
"в подавляющем большинстве случаев ООП — это такие модули"
"X as File"
Гонг вопрос: где тут ооп, а где тут нет ооп?
Всё смешалось... Кони... Люди... (с) кто-то
Yuuri
26.07.2021 20:51И объекты в окамле малопопулярны, похоже, потому что львиная доля случаев их применения покрывается старыми добрыми (в ML) модулями.
libroten
22.07.2021 17:04+2Повторяющиеся вызовы функций все же несколько лучше повторяющегося кода их реализации, сопровождающегося комментарием.
third112 Автор
22.07.2021 18:25-1Чем лучше?
mk2
22.07.2021 19:05+1Например, если в реализации найдётся ошибка, то её достаточно исправить в одном месте.
third112 Автор
22.07.2021 20:06Да, это так. И я это имел в виду, когда сказал про повторы фрагментов. Но речь шла об огромных именах для замены комментов.
libroten
23.07.2021 09:43При грамотной декомпозиции, огромные имена просто не понадобятся
third112 Автор
23.07.2021 11:42Ну и как впихнуть в значимое имя фразу: загрузить из архивного файла, записи для товарных вагонов, расшифровать их, пустые вагоны добавить в таблицу свободных вагонов? Так чтобы было понятно какие действия совершает прога.
lair
23.07.2021 11:47+1свободныеВагоны.добавитьИзАрхивногоФайла(...)Какая разница, расшифровывает оно их или нет?
third112 Автор
23.07.2021 12:11Очень большая. С шифрованными записями прога не сможет работать.
lair
23.07.2021 12:13+1Это значит, что при чтении вы их всегда расшифровываете, и именно поэтому совершенно нет необходимости это указывать в названии операции.
third112 Автор
23.07.2021 12:30Не значит. Нпр., для ускорения поиска по БД поле "тип записи" можно не шифровать. Если тип записи = "ТВ", то это запись товарного вагона.
lair
23.07.2021 12:32+1Но у вас не операция поиска, у вас операция загрузки свободных, а ее нельзя сделать без расшифровки. Пойнт в том, что для получателя, которому нужен список свободных вагонов, пофиг, пришлось вам их расшифровывать, или нет. Какая разница?
third112 Автор
23.07.2021 12:44Есть: загрузить из архивного файла, записи для товарных вагонов. Это может значить найти и загрузить.
Пойнт в том, что для получателя, которому нужен список свободных вагонов, пофиг, пришлось вам их расшифровывать, или нет.
Согласен, что конечному юзеру пофиг. А программисту который пришел на место разраба очень важно понять, почему в методе добавитьИзАрхивногоФайла после чтения идет много строк кода. Напомню, эта ветка обсуждения началась с идеи отказа от комментов, и замены их именами.
unsignedchar
23.07.2021 13:22+1А программисту который пришел на место разраба очень важно понять, почему в методе добавитьИзАрхивногоФайла после чтения идет много строк кода.
Много строк кода вынесены в функцию DecryptDataFromDB, например. Программист понимает, что это что-то связанное с расшифровкой.
third112 Автор
23.07.2021 13:30Программисты — они понятливые, но вместо того, чтобы в одной строке коммента прочесть, программисту нужно бегать по разным функциям. Что быстрее? эргономичнее?
lair
23.07.2021 13:40+1Нет, не надо ему никуда бегать.
Покажите уже пример, а то мне кажется, мы друг друга не понимаем.
third112 Автор
23.07.2021 14:33Я показал:
//загрузить из архивного файла, записи для //товарных вагонов, расшифровать их, пустые //вагоны добавить в таблицу свободных вагонов
third112 Автор
23.07.2021 14:40Cоотносится, как и всякий комментарий. Нпр.:
begin loadFile; //загрузить из архивного файла, записи для //товарных вагонов, расшифровать их, пустые //вагоны добавить в таблицу свободных вагонов nextProc; end;
third112 Автор
23.07.2021 14:47В процедуре loadFile; просто формат Хабра не позволяет разместить этот вызов и следующий комментарий в одну строку. На практике такой проблемы нет.
lair
23.07.2021 14:50+1Т.е. этот комментарий видит тот, кто вызывает процедуру, а не тот, кто ее правит. Тогда:
- его придется повторять (и поддерживать актуальным) везде, где процедура вызывается
- он содержит ненужную информацию (выше уже обсудили, что вызывающему нужно только знать, что и куда будет добавлено)
- не решает озвученную вами же проблему с "программист, который пришел править
loadFileне понимает, зачем там столько кода", потому что вот как раз этому программисту этот комментарий не виден
Решение вида
data = Data.read() data.freight //товарные data.free //пустыелишено всех описанных проблем, и комментарии в нем только для целей демонстрации сейчас, в коде они нужны не будут.
third112 Автор
23.07.2021 15:47Можно записать коммент в определение процедуры loadFile:
procedure loadFile; //загрузить из архивного файла, записи для //товарных вагонов, расшифровать их, пустые //вагоны добавить в таблицу свободных вагонов beginВ Вашем решении не понял: что делают методы freight и free?
lair
23.07.2021 15:50+1Можно записать коммент в определение процедуры loadFile:
Тогда возникает следующий вопрос: а почему бы их просто не заменить понятным кодом:
procedure loadFile; begin loadFromArchive; decrypt; //и так далее endДля кого эти комментарии?
В Вашем решении не понял: что делают методы freight и free?
Это не методы, это свойства (или атрибуты структуры). Возвращают загруженные, соответственно, все товарные вагоны и свободные вагоны. Если все товарные вагоны не нужны, а нужны только пустые, можно упростить до:
data = Data.readFreeCars()
third112 Автор
23.07.2021 16:09Если две строки рядом: одна за другой, то читать легко. А если:
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
unsignedchar
23.07.2021 16:31Применительно к этому куску кода.. exception'ов разве в Delphi не завозили?
third112 Автор
23.07.2021 16:41Завозили, но речь не о том. Речь про отказ от комментов и про использование только значимых имен. Чем больше строк между такими именами — тем труднее читать, тем привлекательней комменты.
lair
23.07.2021 16:53Неа, комменты все еще не привлекательны, потому что они требуют дополнительного труда по поддержанию, и все еще не отвечают на вопрос "что происходит в этом месте кода".
third112 Автор
23.07.2021 17:01Ну ИМХО это уже философский вопрос: насколько реальность отвечает нашим ожиданиям, Статья про разработку новых алгоритмов, и, в этом случае, комменты особо важны: читаем, что хотел автор, и смотрим код: что у него получилось.
lair
23.07.2021 17:05+1Статья про разработку новых алгоритмов, и, в этом случае, комменты особо важны: читаем, что хотел автор, и смотрим код: что у него получилось.
Вот именно поэтому комменты надо писать там, где алгоритм, который нетривиальный, и не надо писать там, где инфраструктура.
В вашем примере, который про загрузку файлов, как видим, комментарии избыточны.
third112 Автор
23.07.2021 17:20decrypt м.б. нетривиальный по новому алгоритму и
loadFromArchive может быть новым. Может новый драйвер на асм.
lair
23.07.2021 17:25В данном примере это не так. Если же алгоритм новый, то комментарии должны сопровождать код, а не быть от него отделены.
lair
23.07.2021 16:52… то тоже легко, более того, хорошо видно, когда-таки началось дешифрование. Особенно если не забывать пустые строки вставлять.
А еще можно обработку ошибок переделать, и оно обратно схлопнется.
third112 Автор
23.07.2021 17:07Пустые строки сродни комментам?
Кроме обработки ошибок, потом может новый код добавиться.
lair
23.07.2021 17:12Пустые строки сродни комментам?
Нет, пустые строки сродни разделению текста на абзацы.
Кроме обработки ошибок, потом может новый код добавиться.
… а вы в этом случае комментарий сверху тоже обновите?
lair
23.07.2021 17:24Вот это и есть та самая лишняя работа. Намного выгоднее вынести этот лишний код в отдельную процедуру, сохраним читабельность.
third112 Автор
23.07.2021 17:32И чтобы узнать, что делает этот код нужно лезть в отдельную процедуру.
lair
23.07.2021 17:44И чтобы узнать, что делает этот код нужно лезть в отдельную процедуру.
Нет, достаточно прочитать название процедуры.
lair
23.07.2021 17:52Нет. Уже обсуждали, что для пользователя важно только то, что она загружает данные, поэтому
loadData.
lair
23.07.2021 18:13Пользователь процедуры — тот программист, который ее вызывает. Тот, для кого вы комментарии пишете. Поэтому да, доступен.
third112 Автор
23.07.2021 18:30В таком случае, возможно, он напишет:
loadFile;
decrypt;при достаточной области видимости decrypt результат будет плачевным.
lair
23.07.2021 18:38при достаточной области видимости decrypt результат будет плачевным.
Это та причина, почему область видимости должна быть минимальной.
А еще это та причина, почему
decryptне должен работать с общим состоянием, тогда ничего плачевного произойти не сможет по определению.
lair
23.07.2021 19:01Не очень понятно, что вам мешает писать код так, чтобы он соответствовал вашим желаниям.
third112 Автор
23.07.2021 19:54Я про Ваши желания:
"область видимости должна быть минимальной",
"decrypt не должен работать с общим состоянием".
lair
23.07.2021 20:08И я про то же самое. Что вам мешает сделать
decryptс минимальной видимостью и не давать ему работать с общим состоянием?
third112 Автор
23.07.2021 20:12В общем случае decrypt должен работать не только с loadFromArchive. М.б. в последующих версиях.
lair
23.07.2021 20:17В таком случае, эта процедура будет доступна вызывающему программисту безотносительно того, сделали вы комментарии или нет. Защищайтесь типами, и будет вам благо.
lair
23.07.2021 20:32Давайте начнем с простого вопроса: а как вам комменты помогуть защититься?
А так-то, защищаться очень просто: если
decryptпринимает толькоbyte[], а возвращаетCar[], и при этомloadDataвозвращаетCar[], программисту неоткуда будет взятьbyte[], чтобы их передать вdecrypt.
third112 Автор
23.07.2021 20:42Неубедительно. Если decrypt могут вызывать другие процедуры, то decrypt должен работать с их данными. А иначе — абсурд.
а как вам комменты помогуть защититься?
Коммент с описанием loadFile после заголовка сообщит, что тут decrypt уже использован.
lair
23.07.2021 20:47+1Неубедительно. Если decrypt могут вызывать другие процедуры, то decrypt должен работать с их данными.
Тем не менее, вход и выход у
decryptвсегда отличаются (или можно сделать так, чтобы отличались), потому что зашифрованные и расшифрованные данные — это разное. Это прекрасный способ защититься от случайного дешифрования чего угодно.
lair
23.07.2021 21:03Вход и выход типа string, иначе какой смысл делать decrypt видимым?
Прямой. Есть куча полезных сигнатур
decrypt, начиная сT decrypt<T>(Encrypted<T>), черезT decrypt<T>(Encrypted)и заканчиваяstring decrypt(Encrypted)иstring decrypt(byte[]). Было бы желание сделать код безопасным — будет и решение.Вы так и не ответили, а комментарий-то вас как защитит?
lair
23.07.2021 21:18+1Это никак не помешает программисту вызвать decrypt самому. Комментарии читают не всегда. А разумные типы и узкие области видимости — помешают, просто не скомпилируется.
Или вот тоже: у вас A вызывает B, B вызывает C, а C вызывает
decrypt— вы на всей цепочке вызовов будете писать "вызывает decrypt"?
third112 Автор
24.07.2021 19:02-2Комментарии читают не всегда.
Это проблема тех, кто не читает.
вы на всей цепочке вызовов будете писать "вызывает decrypt"?
Не надо доводить до абсурда. Серебряной пули нет.
lair
24.07.2021 20:22+1Это проблема тех, кто не читает.
Тогда и то, что программа ломается, когда кто-то вызывает
decryptпослеload— тоже проблема того, кто вызывает. Симметрично.Не надо доводить до абсурда. Серебряной пули нет.
Серебряной пули нет, но есть более и менее надежные способы. Типы и сокращение видимости — более надежно, чем комментарии.
unsignedchar
23.07.2021 14:59+1В процедуре loadFile
Я лично не люблю, когда функция loadFile, кроме загрузки файла, делает ещё какие-то не сильно очевидные действия (варит кофе/форматирует диск Ц/взрывает Звезду Смерти). Например, во всяких инспекторах классов имена функций видно, а комментарии — нет. Нужно помнить что Class_a.loadFile — просто загружает файл, а Class_b.loadFile — загружает файл и варит кофе.
Но у каждого свои предпочтения.
third112 Автор
23.07.2021 17:58-1Если ТЗ требует формат после удачной загрузки файла, то желание заказчика — закон исполнителю. И кофе можно сварить: хозяин — барин ;)
unsignedchar
23.07.2021 13:42+1Что быстрее? эргономичнее?
Отдельная функция, конечно ;)
При просмотре кода — если нет необходимости смотреть на код расшифровки — туда просто не смотрят. Если есть необходимость — переход в функцию это 1 щелчок мыши, в чем проблема?
При отладке — просто не заходим в функцию, это быстрее, чем пролистывать на 200 строк вперед.
Но я не настаиваю ;)
lair
23.07.2021 13:39Есть: загрузить из архивного файла, записи для товарных вагонов. Это может значить найти и загрузить.
Потребителю это все равно не важно.
Согласен, что конечному юзеру пофиг.
Ну так дескриптивное имя операции — он для конечного юзера (операции) делается.
А программисту который пришел на место разраба очень важно понять, почему в методе добавитьИзАрхивногоФайла после чтения идет много строк кода.
А для этого программиста эти "много строк кода" выносятся в метод с понятным названием
decrypt, и у него тоже вопросы пропадают. Так оно и работает.
SeregaPositive
22.07.2021 10:58+1Абсолютно также подумал когда читал.
Классический рефакторинг ExtractMethod.
Делаем примерно следующее:
BoxcarsData = LoadBoxcarsFromArchive();
Boxcars = ParseBoxcarData(BoxcarData);
FreeBoxcars = GetFreeBoxcars(Boxcars);
UpdateFreeBoxcarsList(FreeBoxcars);
1MK-Ultra
22.07.2021 06:58-4Чепуха какая то. В delphi 7 юникод есть. Современные языки это неповоротливые великаны. Попробовал недавно поучится rust. Современный. Так оказывается, чтобы скомпилировать, ему нужно весь microsoft visual c++. И ещё кучу прибабахов. Код получается ну очень огромным.
Teplo_Kota
22.07.2021 10:34+5Что-то вы недоучили. "Hello World" под Линукс весит 151 байт, под винду 1500 байт. Но конечно, если собирать в дебаг-режиме, с настройками по умолчанию, которые пихают вообще всё, что можно, в бинарь...
Revertis
22.07.2021 12:05Не весь MS visual C++, а только tools.
1MK-Ultra
22.07.2021 16:13Которое весит мегобайт 900. И хрен поймёш как настроить потом всё это.
Revertis
22.07.2021 16:17Ну да, весит много. Но у вас разве нет свободного гига для нужд разработки?
Плюс, ничего больше настраивать не надо.
mapron
22.07.2021 16:57Ну так-то да, clang 12 под win почти 2 гб установленный занимает. и это с учетом что там нет STL еще, которая есть в MSVC.
Пакет conan который я делал где чисто под 1 платформу компилятор и хидеры, для последней версии 300 мб в распаковке на диске.
Но компилятора мало, скорее всего еще Windows SDK нужен.
Опять же под одну платформу (х64) все необходимые файлы в распаковке примерно 500 Мб.
Ну и сравнить например с IDE Qt Creator — где нет ничего (ни компилятора, ни дебаггера, ничего, просто редактор со всеми ништяками) — 600 Мб на диске.
Не выглядит как что-то на что стоит жаловаться. я бы только на clang жаловался, какого он жирный такой)
p.s. ну а настройка это да, это смех — установил компилятор и все, популярные ide подхватят все сами. для консольки — vsvarsall.bat дернул, шо еще надо-то…
1MK-Ultra
23.07.2021 15:58-1Да не хочу я больше это изучать. Вот C/C++ другое дело. mingw скачал и установил. Больше никаких манипуляций. Если конечно не понадобится что то вроде qt.
DirectoriX
23.07.2021 19:54Так ведь у Rust аж на 1 манипуляцию больше, чем у C/C++:
- Устанавливаем C++ build tools от Microsoft или MinGW
- Запускаем rustup, который установит Rust
snuk182
22.07.2021 12:19По умолчанию почему-то ставится msvc-версия. Если насильно ткнуть при установке в gnu-версию, то не надо ничего, рядом сам ставится mingw.
dllmain
22.07.2021 12:43Если насильно ткнуть при установке в gnu-версию, то не надо ничего, рядом сам ставится mingw.
Думаю, человек был недоволен зависимостью от компилятора другого языка, а не тем, что нужно зависимости руками доставлять.
kosmonaFFFt
22.07.2021 15:26Он может использовать и gcc. Не обязательно visual c++.
Revertis
22.07.2021 16:18Только бинарники будут в 10 раз больше, и некоторые зависимости под чистую винду не будут находиться.
lobzanoff
22.07.2021 08:55Насколько помню, в 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"ну и, если необходимо, добавить в этот список какие-то другие используемые шрифты.
third112 Автор
22.07.2021 11:22Я просто нашел в сетке свободную б-ку стандартных компонентов в юникоде и переименовал каждый компонент в файле проекта с их списком.
Sm1le291
22.07.2021 09:27-2Почему я продолжаю использовать устаревшие виртовский Pascal и Delphi-7
Тут только один ответ, вам лень выучить что то новое. А поводов оправдаться, ну вон целая статья найдется
third112 Автор
22.07.2021 11:26Почему лень. Я упоминал OpenCV, CUDA — учил самые свежие версии. Очень много времени у меня уходит на графы — много читаю интересных статей. Ну, и на химию.
Sm1le291
24.07.2021 12:50-2Ну вот и ответ, нельзя быть хорошим химиком и программистом, точнее можно, но очень сложно.
И тут явно видно что вы не справляетесь, так как пишите на мёртвом языке, который сейчас слабо востребован на рынке.
На всякий случай, слабо, это не значит совсем, вы же как то нашли работу.
Не обижайтесь пожалуйста, если комментарий вас задел, просто снял вам розовые очки.
Все эти компоненты vcl были хороши для своего времени. Но сейчас на первое место выходит поддерживаемость, поддержка многопоточности, асинхронности из коробки, и всякого синт сахара типа async await.
То что вы можете быстро накидать комп на форму и запустить апп на винде это хорошо, но сейчас все ушло в веб, и я сейчас не только о фронте.
Бэк энд тоже сейчас чаще дёргается по grpc или rest
third112 Автор
24.07.2021 17:22+2А хорошим химиком и физиком можно быть? Много людей работают в физхимии, в Москве 2 НИИ РАН: физхимии и химфизики. Получается работать на стыке наук. Почему Вы думаете, что невозможно работать на стыке химии и CS?
Это Вы не обижайтесь: Вы в розовых очках полагаете, что использование новейших технологий делает Вас хорошим программистом.
unsignedchar
24.07.2021 17:36+1И тут явно видно что вы не справляетесь
Не видно ;) Статья как раз о том, что справляется со своими задачами с помощью устаревшего языка.
HemulGM
04.08.2021 14:22Версия языка Delphi обновляется каждый квартал. Delphi давно не привязан к одной платформе (Windows) и позволяет писать и на Linux/Android/iOS/MacOS/Windows один кроссплатформенный код. Давно умеет в быструю и простую асинхронность (TThread/TTask/TTaskPool) (куда лучше чем async/await, например в шарпе).
Дизайнер окон мощнее любого из существующих (погуглите на эту тему, если есть сомнения).
Помимо всего этого, погуглите Delphi TMS Web, Delphi uniGUI.
lair
04.08.2021 14:37Давно умеет в быструю и простую асинхронность (TThread/TTask/TTaskPool) (куда лучше чем async/await, например в шарпе)
Простите, а как вы это сравнили? Потому что таск-пул — это совсем не то же самое, что async-await.
0xd34df00d
22.07.2021 10:08+1Дошёл до абзаца про математически строгие доказательства, уж было напрягся, но так и не понял, как вы это решаете на паскале.
third112 Автор
22.07.2021 11:39На псевдокоде. Нпр., если в алгоритме 2 цикла (1 вложен), и делают m и n шагов, то в наихудшем случае алгоритм сделает mn шагов.
Alexandroppolus
22.07.2021 12:16если в алгоритме 2 цикла (1 вложен), и делают m и n шагов, то в наихудшем случае алгоритм сделает mn шагов.
По разному бывает. Например, перевоплощение массива в бинарную кучу выглядит как O(n*ln(n)) - каждый элемент надо "просеивать", что вроде как ln(n). А по факту выходит O(n) на всё про всё.
third112 Автор
22.07.2021 13:58Согласен. К этому подходу много критики. Так А.А.Зыков критикует в начале книги Тория графов.
0xd34df00d
22.07.2021 20:24+1Этак вы только сложность алгоритмов оцените сверху, но не их корректность.
third112 Автор
22.07.2021 20:49Верно. Но если у нас граф с n вершинами и "координаты" текущей вершины (i,j) меняют два цикла от 1 до n, то можно сделать вывод, что в матрице смежности каждый элемент будет просмотрен 2 раза.
0xd34df00d
22.07.2021 20:58Как из этого следует, что ваш алгоритм даст правильный ответ?
third112 Автор
22.07.2021 21:07Из этого следует, что подзадача просмотра м-цы смедности решается корректно. Аналогично для других подзадач.
0xd34df00d
22.07.2021 21:19volatile int sink = 0; for (int i = 0; i < n; ++i) for (int j = 0; j < m; ++j) sink = arr[i][j];Это правильная часть алгоритма?
third112 Автор
22.07.2021 21:31-1Переведу на Pascal:
var sink :integer; begin for i:=1 to n do for j:=1 to m do sink := arr [i,j]; end;Если правильно перевел, то правильная.
0xd34df00d
22.07.2021 21:41+1Но ведь он функционально эквивалентен алгоритму
sink = arr[n, m], который проходит вообще только по одному элементу из всех. В чём его правильность?third112 Автор
22.07.2021 21:48-1Согласен. Поэтому правильнее написать так:
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;0xd34df00d
22.07.2021 21:52Что значит правильнее? Вы же согласились, что предыдущий вариант тоже правильный. Куда уж правильнее?
Вот я написал ваш алгоритм на графах, который возвращает последнее значение в матрице смежности (или вообще 42). Сложность — O(1). Почему бы вам не заменить вашу реализацию на мою?
third112 Автор
22.07.2021 22:03-2Ваш алгоритм м.б. удобен для отладки: смотрите под отладчиком значения sink на каждом шаге внутреннего цикла.
0xd34df00d
22.07.2021 22:21+4У меня почему-то никак сегодня не получается доносить свои мысли, так что забейте, все алгоритмы правильные.
starpearl
22.07.2021 10:12+1Согласен с автором.
FreePascal у меня, конечно, есть, но не пользуюсь. EmbarcaderoSydney тоже живёт в виртуалке. Для прототипов предпочитаю delphi7; живёт в виртуалке windows7 и проблем с юникодом не наблюдается. Получаются быстрые и надёжные прототипы, хоть в многопотоках, хоть в процессах, линкуется с чем угодно в себя и из себя.
Зачем учить пытон(тем более конкретно третий) сегодня, если завтра его сменит крокодил ?
P.S. Паскалем не ограничен = использую языковые инструменты в зависимости от задачи.
v1000
22.07.2021 10:29+3Delphi-7 напоминает мне Windows XP. Устарел, но работает. И иногда проще ничего не трогать, если он выполяет все цели, для которых используется.
DrPass
22.07.2021 11:23+5У меня, кстати, она стоит на компьютере. Я для каких-нибудь быстрых поделок её держу. Меня восхищает то, что она работает мгновенно. В смысле, вообще мгновенно — ты только нажал на сборку, а софтина уже собралась и запустилась.
third112 Автор
22.07.2021 13:31Спасибо за замечание. Добавлю в статью. Я уже подзабыл "прелесть" медленных компиляторов.
0xd34df00d
22.07.2021 20:25+2Современный язык с реплом даст вам те же ощущения, только ещё с современными ништяками (которые, конечно, для разных людей разные важны).
DrPass
22.07.2021 23:29+1Современный язык с реплом даст вам те же ощущения,
Я не знаю про существование современных языков с реплом, которые несколько сотен тысяч строк компилируют за доли секунды, но даже если бы были, для тех же ощущений мне понадобится ещё и IDE, где я могу мышкой нарисовать UI, причем с живыми данными в дизайнтайме.
dllmain
22.07.2021 12:38Такое ощущение, что вы пытаетесь оправдать свою лень освоить какой-либо другой ЯП. Текст полон стереотипов. Вот это например:
Pascal-образный (Pascal-like) псевдокод интуитивно понятен (всем кто знаком, хотя с одним универсальным ЯП)
конечно же, не использовать пресловутый goto
Да, именно лень является здесь основным мотивом:
Понятно, что возьму эти процедуры из своего старого кода. Но почему Delphi-7, а не более новое? — К сожалению, проблемы несовместимости.
Неясно только, почему бы в таком случае не сказать прямо - меня всё устраивает и переходить на что-то другое необходимости я не вижу.
third112 Автор
22.07.2021 12:39Про лень уже отвечал. У меня много других дел. Про графы и химию читать...
dllmain
23.07.2021 19:03+1Тогда почему написали не "у меня нет времени", а "интуитивно понятен", "goto" и другие отмазки?
Sm1le291
25.07.2021 13:41-1Да, чувак реально странен. Я ему выше написал что есть люди которые 100 процентов времени тратят на айти и выдают гораздо лучший результат на новых языках, а он все по химию какую то.
Кстати по компиляцию о которой здесь много говорили, сейчас VS и. Net языки поддерживают hot reload. Тоже самое и для Java script фреймворков, типа ангуляра, в итоге я приложение иногда заново по несколько дней не компилирию, а изменения применяются мгновенно. Но автору поста это невдомек, у него химия и минусики поставить на комменты)
third112 Автор
25.07.2021 14:29-1Мне плевать, как меня называют. Но дам совет, который м.б. поможет улучшить Вашу карму: я Вам, любезнейший, не "чувак". Выбирайте выражения — не в подворотне находитесь.
Alexey2005
22.07.2021 12:38+8У Delphi есть огромное преимущество перед современными языками программирования (за исключением разве только C#): это полный комплект, всё в одном. Установив Delphi, вы получаете весь инстурментарий, а также полностью интегрированный с ним редактор, отладчик, визуальный редактор, библиотеку компонентов и справочную систему. Причём качество справки таково, что для подавляющего большинства современных ЯП попросту недосягаемо.
Соответственно, сразу после установки оно готово к работе. Вы можете тут же, буквально нажатием одной клавиши, собирать и запускать программу. Никаких прописываний путей и прочей настройки — это цельный продукт, а не паззл, который надо сперва собрать из кусочков. Точно так же вы можете сразу отлаживать, расставляя точки останова в редакторе. И никогда не будет проблем из-за того, что убогий gdb опять как-то не подцепился редактором кода или чего-то не нашёл. Вы сразу можете вызвать справку кликом по любому идентификатору, и для этого ничего не потребуется настраивать.
По сравнению с этим, инфраструктура современных ЯП кажется до ужаса убогой и неудобной. Это конструктор «собери сам», причём даже после сборки такого удобства как в Delphi не будет — вечно хоть что-то да отвалится.starpearl
22.07.2021 13:04+1Да, всё )))правильно: раньше не знали, что программировать надо весело и куульно. И ещё плюс, как заметили выше, скорость сборки. Но есть )))нюанс. Это до середины нулевых у российского программиста стояло разнообразное ''современное'' ПО для любой области интересов. Потом пришли лицензии и началось... Например, embarcadero вовсе не плохой продукт, но посмотрите на его цену или цену других профессиональных инструментов. Поэтому везде и широко бесплатный пытон для учёбы и прототипов.
1MK-Ultra
22.07.2021 16:23Согласен. Но заказчики не хотят delphi. Хотят C++, С#, Python, Haskel. Если хочеш зарабатывать, а не философствовать, придётся использовать эти языки. Раньше можно было пол деревянными досками накрывать, и было хорошо. Теперь ни кто деревянные полы не хочет, хотят ламинат. Не скажеш же заказчику, давайте я вам лучше из сосновых досок пол сделаю.
Alexey2005
22.07.2021 16:43Тут скорее вместо отработанной технологии строительства кирпичного дома заказчик хочет каркасник, потому как он быстрее и дешевле, да и вообще современнее.
Вот только если состояние кирпичного дома оценить довольно легко, то чтобы оценить состояние каркасника потребуется весьма дорогостоящая экспертиза. Дом может выглядеть идеально, но на самом деле там все балки давно сгнили и вся конструкция вот-вот сложится…
HemulGM
04.08.2021 14:28Заказчик хочет ламинат. Ламинат - это инструмент? Нет, это результат работы. Заказчику не важно, каким инструментом ты будешь укладывать ламинат. Главное, чтоб он был уложен и уложен хорошо.
1MK-Ultra
06.08.2021 08:35Вот оказывается не всё равно. Посмотрите заказы на фрилансе. Везде требования к языку, и даже к среде разработки.
HemulGM
06.08.2021 09:01Если делать студентикам задачки, то конечно они просят на конкретный язык. А если найти на фрилансе нормальный заказ на создание той или иной программы, то только единицы могут указать конкретную технологию. И то, в таком случае достаточно поинтересоваться "почему?" и можешь сам предложить технологию. заказчику будет не важно.
1MK-Ultra
06.08.2021 09:09Реч идёт вовсе не о студентиках. Ну, хорошо, посмотрите вакансии. Где там требуется программист со знанием Dephi 7?
HemulGM
06.08.2021 09:43При чем тут Delphi7? Современная среда разработки для Delphi - это RAD Studio 10.4.X, среда вышедшая в этом году.
И нет смысла спорить о вакансиях. Их мало, но они есть. С хорошей зп.
0xd34df00d
22.07.2021 20:27+1Но это же такое, одноразовое преимущество. Среду вы в любом случае настроили один раз, а потом существенно, асимптотически больше времени тратите на работу в ней. Поэтому лично меня не очень волнует, сколько времени я потрачу на начальную настройку, если потом моя производительность как программиста это время с лихвой компенсирует.
Alexey2005
22.07.2021 21:07А потом вы захотите поставить эту среду себе ещё и на ноут, и там придётся настраивать заново, тратя кучу времени, чтобы всё работало вот как на десктопе, потому что к тому времени вы уже забудете, где и что ставили и как всё это сопрягали.
Мало того, весь этот инструментарий слишком сильно «зацеплен» за конкретную систему и потому очень хрупок. Перейдя допустим с Ubuntu на что-то ещё вы тоже потеряете все настройки и будете лепить всё заново.
Вот я, к примеру, из-за этого на Ubuntu 16.04 сидел до упора, пропустив 18.04, потому что был уверен, что при переходе всё сломается и надо будет настраивать заново. И да — когда на этом старье стало уже совершенно невозможно сидеть и пришлось переползать на 20.04, оно таки сломалось, и пришлось заново возиться с настройкой.
Причём каждый раз настройка — это не «вот потратил два вечера и дальше радуйся». О нет, потом в процессе работы то и дело натыкаешься на разные проблемы и шероховатости ещё не одну неделю. Всё время где-то что-то вылезает, и комфортность работы так себе, пока окончательно не отшлифуешь.0xd34df00d
22.07.2021 21:22+2А потом вы захотите поставить эту среду себе ещё и на ноут, и там придётся настраивать заново, тратя кучу времени, чтобы всё работало вот как на десктопе, потому что к тому времени вы уже забудете, где и что ставили и как всё это сопрягали.
Не придётся, у меня все настройки в гите. Достаточно склонировать репозиторий с моего гитхаба и запустить скрипт, который раскидает симлинки как надо.
Мало того, весь этот инструментарий слишком сильно «зацеплен» за конкретную систему и потому очень хрупок. Перейдя допустим с Ubuntu на что-то ещё вы тоже потеряете все настройки и будете лепить всё заново.
У меня вообще дистрибутив с роллинг-релизом, и почему-то ничего не отваливается.
HemulGM
04.08.2021 14:34Разработка в Delphi достаточно быстра. Библиотеки для питона, которыми он так "славится" кто-то пишет. Т.е. такую же работу можно проделать и для Delphi. Т.е. опустим аргумент что "на питоне библиотеки для всего".
Далее, процесс разработки на Delphi не уступает питону. За исключением только что нужно освобождать память вручную.
0xd34df00d
04.08.2021 16:49Т.е. такую же работу можно проделать и для Delphi.
Только её надо проделать.
Т.е. опустим аргумент что "на питоне библиотеки для всего".
А вы этот аргумент будете для любого языка опускать, который поддерживает библиотеки?
Далее, процесс разработки на Delphi не уступает питону.
Почему вы вообще сравниваете с питоном? Я считаю питон ужасным языком для разработки, и для меня это утверждение не то чтобы сильно в пользу дельфи.
HemulGM
04.08.2021 23:36Сравниваю с ним из-за коммента выше и по причине его бессмысленной популярности, из-за которой его пихают уже просто всюду, где он даже на минималках не вывозит.
У делфи масса преимуществ, о которых вам уже не один раз рассказывали. А в купе с возможностью быстрой разработки, быстрым внедрением собственных инструментов в среду и многочисленными инструментами среды из коробки, он является мощным инструментарием.
Не говоря уже о том, что язык развивается семимильными шагами.
0xd34df00d
05.08.2021 23:32+1Развитие — это хорошо. Что там нового и, желательно, отсутствующего в большинстве прочих языков запилили?
HemulGM
06.08.2021 09:07-1А для начала необходимо указать, что имеется сейчас из того, чего нет в других языках.
1. Скорость и лёгкость разработки. Софт с GUI писать одно удовольствие.
2. Масса коробочных решений. Я написал софт для просмотра 3D панорам в 20 строк, в только что установленной среде.
3. LiveBindings и прочееНу а что нового... Во-первых я не знаю с какого момента для вас что-то будет новым. Если вы знакомы с делфи только по Delphi 7... То разговор будет долгим.
forever_live
09.08.2021 18:29Извиняюсь, а можно на этот софт для просмотра 3D панорам в 20 строк посмотреть? Лучше, конечно, в исходниках, ну или в виде HOWTO?
HemulGM
09.08.2021 18:37В среде есть штатные средства для создания 3D сцены. Как в юнити (почти). Исходника нет, т.к. он перерос в большой проект. Шаги следующие:
В дизайнере:
Добавляем на форму Viewport (сцена).
На сцену добавляем сферу.
На сферу помещаем материал (без освещения).
Приближаем камеру чтобы оказаться внутри сферы.
Кидаем компонент диалогового окна выбора файла
Добавляем кнопку
Выбираем сферу и добавляем её обработчик событий OnMouseMove, OnMouseDown, OnMouseUp
В коде:
OnMouseDown - флаг, что нажата мышь и запоминаем координаты мыши
OnMouseUp - снимаем флаг
OnMouseMove - 5-6 строк для поворота сферы в зависимости от смещения мыши
На нажатие кнопки выполняем диалоговое окно, выбранный файл загружаем в материал (3 строки)
Готово. Получаем кроссплатформенный софт для просмотра панорам. Можно собрать под винду, андроид и ios из коробки.
Это всё штатными средствами без каких-либо сторонних библиотек.
Есть и более быстрый способ. Есть репозиторий компонента, который вмещает в себя все вышеперечисленные шаги (+некоторые визуальные удобства, плавный скрол и т.д.).
С ним достаточно будет кинуть компонент на форму и добавить кнопку выбора панорамы. Т.е. 3 строки.
HemulGM
09.08.2021 19:13Могу скинуть ссылку на видео. Там проделанная работа за 3 дня. Все данные идут из сети. Софт собирается на андроид. Нацелен на планшеты. Но только в вк
https://vk.com/video58553419_456239669
HemulGM
09.08.2021 20:22Панорамы в видео, к слову, тоже сделаны в программе написанной на Delphi. Речь о программе для дизайна интерьера. И она написана как раз на Delphi 7. Т.е. работа со сценой и рендеринг всё сделано в одной программе.
HemulGM
09.08.2021 20:51Собственно я заморочился и добавил в гит. Код, который писался находится только в файле .pas (и то только то, что в процедурах внизу). Остальное автоматически генерируемые файлы.
https://github.com/HemulGM/Pano3Dforever_live
10.08.2021 21:42Спасибо, посмотрю. Добрался глянуть на работе, что есть в D10.3 (легальной). Нашёл там упомянутые ключевые слова, TViewPort3D и даже TForm3D, если визардом создавать сразу 3D приложение.
HemulGM
10.08.2021 21:51Не обязательно создавать TForm3D, TViewPort3D можно добавить в любой момент в любых кол-вах (в FMX конечно же)
forever_live
10.08.2021 22:02Да, я понял, что TViewPort3D можно и на FMX.TForm кидать. Вот пока не изучил, что же даёт TForm3D по сравнению с TForm. Надо читать, может что полезное из этого родится.
belch84
22.07.2021 13:00+2Исследование динамической системы («гиперхаос Рёсслера»)
1MK-Ultra
22.07.2021 16:24+1Весь этот код, запросто можно переделать на C/C++
belch84
22.07.2021 16:54В добрый час! Если уж вы это произнесли, то, когда переделаете — сообщите, пожалуйста, здесь, в комментариях, о завершении работы и выложите результаты.
Если говорить серьезно, то в своём приложении я практически не пользуюсь никакими сторонними компонентами, а у вас в процессе переделки это может и не получиться. В любом случае, интересно будет взглянуть на то, что у вас выйдет.1MK-Ultra
23.07.2021 16:04Не охота мне переделывать. Да и смысла нет. И времени тоже. Вроде даже специальные утилиты у Borland были, для миграции исходников между delphi и cpp builder
belch84
23.07.2021 16:15Я тоже не очень понял, зачем вдруг мой код нужно переделывать на C/C++. Повторю, что он продолжает работать, будучи написанным 30 лет назад (под Windows 10 тоже). Если вы имеете в виду, что C/C++ дадут какие-то уж очень большие преимущества в разработке подобного рода, то в этом у меня большие сомнения. Использование самих по себе C/С++ или ООП не даст большого выигрыша по сравнению с Паскалем там, где нужно писать компилятор формул или процедуры аналитического дифференцирования. Конечно, можно пользоваться сторонними компонентами, но той свободы, которую получаешь, написав всё самостоятельно, при этом не получишь
0xd34df00d
23.07.2021 20:22+2Использование самих по себе C/С++ или ООП не даст большого выигрыша по сравнению с Паскалем там, где нужно писать компилятор формул или процедуры аналитического дифференцирования.
Правильно, для этого лучше брать языки из ML-семейства. Компиляторы и тому подобное на них очень приятно писать.
belch84
23.07.2021 20:35Правильно, для этого лучше брать языки из ML-семейства. Компиляторы и тому подобное на них очень приятно писать
Компилятор выражений — только часть моего приложения, важная, но не едиинственная. Кроме того, нужно достаточно быстрое выполнение множества операций с плавающей точкой, действия с матрицами, возможность динамического выделения/освобождения памяти, работа с графикой. Для всего этого нужен был универсальный язык. Паскаль для этого подходил уже очень давно, и до сих пор он позволяет относительно просто дополнять систему, а также без проблем мигрировать на новые версии компиляторов и новые версии ОС0xd34df00d
23.07.2021 20:39Кроме того, нужно достаточно быстрое выполнение множества операций с плавающей точкой, действия с матрицами, возможность динамического выделения/освобождения памяти, работа с графикой.
Тот же хаскель, по-вашему, этого не умеет?
belch84
23.07.2021 20:49Тот же хаскель, по-вашему, этого не умеет?
Понятия не имею. В 1991 я ни про какие Хаскели ничего не слышал, пользовался тем, что было просто и доступно. За 30 лет настоятельной необходимости в чем-то, кроме Паскаля, и не возникло. Для доказательства того, что Хаскель существенно лучше, нужно было бы написать на нём подобную систему, которая была бы существенно лучше в чем-то (быстрее, или работать на совсем уж разных ОС), да еще и чтобы она работала на всех промежуточных версиях Windows (и даже MS DOS)0xd34df00d
23.07.2021 21:21Ну если всю жизнь заниматься одной программой, то, конечно, необходимости в других языках не возникнет. Они будут даже вредны — действительно, зачем переписывать уже работающее?
belch84
23.07.2021 21:29+1Ну если всю жизнь заниматься одной программой, то, конечно, необходимости в других языках не возникнет. Они будут даже вредны — действительно, зачем переписывать уже работающее?
Это приложение — развлечение для души, и я привожу его историю как пример, иллюстрирующий основную мысль публикации — почему автор до сих пор не отказался от Паскаля. Моё мнение — у автора есть для этого основания
0xd34df00d
23.07.2021 21:39+1На вопрос «почему не отказался от паскаля (кобола, етц)» вполне себе хорошим является ответ «легаси». Серьёзно, без иронии.
Однако, чаще всего интересен вопрос о том, какую технологию выбирать для следующего проекта. Если бы вы сегодня эту систему делали с нуля, то вы бы тоже выбрали паскаль?
belch84
23.07.2021 21:49Однако, чаще всего интересен вопрос о том, какую технологию выбирать для следующего проекта. Если бы вы сегодня эту систему делали с нуля, то вы бы тоже выбрали паскаль?
Не могу ничего ответить, я не полиглот в отношении ЯП. Примерный аналог моего отношения к этому — это похоже на поддержание на ходу какого-нибудь древнего, но красивого автомобиля, при этом автомобиль должен быть сделан так, чтобы это позволить
unsignedchar
23.07.2021 21:23+1и даже MS DOS
Где в 2021 году держат MS-DOS и с какой целью, интересно знать ;)belch84
23.07.2021 21:26Где в 2021 году держат MS-DOS и с какой целью, интересно знать ;)
Наверное, нигде не держат, я говорю о приложении, которое работало под MS DOS, работает под Win10 и является полезным до сих пор
unsignedchar
23.07.2021 21:39Тут дело не в выборе правильного языка, а в Microsoft, которые протянули бинарную совместимость с DOS аж до Windows 10. Программа на Ассемблере под DOS тоже должна работать в Windows, why not. Если прямого доступа к железу не использовать.
belch84
23.07.2021 21:50Программа на Ассемблере под DOS тоже должна работать в Windows, why not. Если прямого доступа к железу не использовать.
Интересно бы взглянуть на такую программу на Ассемблере, особенно без использования доступа к железу
belch84
24.07.2021 07:04Нет, я имею виду програму на Ассемблере с обработкой формул, матричными операциями и элементами трехмерной графики
unsignedchar
24.07.2021 13:58Можно поискать среди старинных демосцен или игр. Они написаны на ассемблере, внутри много матричных операций, некоторые из них, я уверен, запустятся и под windows.
Но это же совершенно не значит, что ассемблер х86 является однозначно наилучшим выбором для долгоиграющего проекта.
1MK-Ultra
26.07.2021 08:39Я недавно устроился в одну организацию. Есть программы под DOS. Причём, просто взять их и выкинуть не получится. Уж очень сильно на них завязано.
1MK-Ultra
26.07.2021 08:36Выигрыш даст. Это больше заказов. Заказчики требуют чтобы было на C++. И ни на какие дельфя и паскали не согласны. Да и ещё за спиной у виска покрутят пальцем.
belch84
26.07.2021 11:00Это приложение — для души, я уже писАл об этом. Его можно использовать в готовом виде, большую часть часть фич — бесплатно (на самом деле, это приложение SHAREWARE с пробным периодом, отнюдь не железобетонной защитой и символической оплатой за официальную регистрацию). Те, кто крутят пальцем — пусть крутят, тем, кто утверждает, что
Весь этот код, запросто можно переделать на C/C++
можно ответить только — ну, запросто переделайте и покажите, что получилось. Можно считать это резьбой по рисовому зёрнышку, на такое заказчиков, конечно, немногоunsignedchar
26.07.2021 11:16В хобби-проектах можно всё, хоть и brainfuck-процессор из рассыпухи собирать. Но слесарь-одиночка крупный проект просто не вытянет. Linux, к примеру, выехал не на гениальности и работоспособности Торвальдса, а на том, что ему удалось организовать командную работу.
belch84
26.07.2021 11:32+1Не претендую на славу Торвальдса, замечу только, что мой, как вы выражаетесь, хобби-проект, существует примерно так же долго, как и Linux. А крупных проектов, которые не просуществовали и пару лет, я видел достаточно, как и тех, за участие в которых должно быть стыдно
nmrulin
03.08.2021 01:40Ну не всем же крупные проекты делать. А в мелких , тот же C++ крайне неэффективен против Паскаля/Дельфи.
Можно один и тот же код из примеров посмотреть на Delphi и C++ Builder, неужели кому-то второй вариант кажется более лаконичным и удобочитаемым?
procedure TForm1.MyButtonClick(Sender: TObject); void __fastcall TForm1::Button1Click(TObject *Sender)
1MK-Ultra
26.07.2021 14:46Для души, это другой вопрос. Для души это правильно. Я вот недавно для души, пентиум первый собрал. Работает. Многие спрашивают, зачем он тебе? Мог собрать посовременней.
HemulGM
06.08.2021 09:38Только производительность Делфи может сравниваться только с срр. Остальные языки проигрывают.
lair
06.08.2021 09:47Делфи может сравниваться только с срр. Остальные языки проигрывают.
Можно, пожалуйста, ссылку на независимое измерение для веб-приложения? Ну не знаю там, что-нибудь на манер вот этого: https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite (где я ни дельфи, ни паскаля не вижу)
HemulGM
06.08.2021 10:07Я бы не хотел на этом сливаться, но отсутствие веб фреймворков на Делфи в этом бенчмарке не говорит о его производительности. Я не использую сам делфи как веб сервер. Хотя на нём есть не мало веб фреймворков. Я был бы рад увидеть их в тестах, но создавать тестовое веб-приложение я не планирую.
Можно провести обычные синтетические тесты и сравнить скорость. Но в сети уже есть сравнения.
lair
06.08.2021 10:37Хотя на нём есть не мало веб фреймворков.
Но в сети уже есть сравнения.Вот я и прошу: можете дать ссылку на независимое сравнение производительности веб-фреймворка на Delphi с веб-фреймворками на других языках?
HemulGM
06.08.2021 11:58Почему именно веб-фреймворки? Это вообще не популярная вещь на Делфи. И я уже сказал, я не использовал веб-фреймворки (только для фронта). Я не знаю где есть тесты.
lair
06.08.2021 12:01Потому что вы сказали о производительности языка без указания сценариев, сказав, что остальные языки проигрывают. Вот я и заинтересовался, стоит ли рассматривать так расхваливаемый вами Дельфи для моих задач.
Пока выходит, что бесполезно.
HemulGM
06.08.2021 12:51Как связана производительность языка и наличие в нём конкретных фреймворков? Язык обладает высокой производительностью. Высокая производительность ни как не гарантирует в языке наличие по умолчанию веб-фреймворка.
Возьми делфи, веб-фреймворк, протестируй если тебе интересно. Я знаю его производительность в других задачах.
DirectoriX
06.08.2021 13:40+1Вы утверждаете, что Delphi обладает высокой производительностью. Ни одной ссылки, ни одного примера (кроме каких-то абстрактных «обычных синтетических тестов») от вас не последовало. Когда вас спрашивают про конкретную область применения — вы отмахиваетесь, мол не для того язык используют. Так для чего же? Можете подкрепить своё утверждение о производительности на примерах, желательно из реального мира, а не на голой «синтетике»?
lair
06.08.2021 13:55Как связана производительность языка и наличие в нём конкретных фреймворков? Язык обладает высокой производительностью.
Я не очень понимаю, что такое "производительность языка". У меня решения, написанные на одном и том же языке, могут отличаться по производительности на порядки. Так что меня интересует производительность конкретного решения на конкретной задаче. Вот TechEmpower запарились и сделали такое сравнение для типовых веб-фреймворков.
А "производительность языка" — это что-то абстрактное, что я никогда в своих задачах не увижу.
Возьми делфи, веб-фреймворк, протестируй если тебе интересно.
Не, мне не интересно тратить свое время на тестирование производительности решения на языке, который может быть даст мне выигрыш в производительности, но ни в чем остальном (из того, что я видел, конечно) не выигрывает у подходов, которыми я сейчас пользуюсь.
HemulGM
06.08.2021 18:46В Делфи совсем не давно появилась возможность собирать код под Линукс. По причине того, что в сервер в 80% - это сервер на Линукс, а компиляции под линукс у Делфи не было - нет и большого количестве веб-фреймворков. Это сейчас есть RESTfull и прочие фреймворки, работа которых возможна в Docker.
Именно по этой причине нет того, что вы от меня требуете и именно по этому Делфи вам на данный момент не подходит.
lair
06.08.2021 18:51… хотя казалось бы, 80% моей разработки идет под Windows, и линкус меня вообще не интересует, Дельфи все равно мне не подходит? Забавно.
Так все же, что с производительностью-то? Или не было, забыли?
HemulGM
06.08.2021 18:51Высокая скорость работы обусловлена тем, что язык компилируемый, строго типизированный и позволяет передавать параметры функций на стеке. Человек, с которым я общаюсь требует конкретное тестирование как веб-сервиса. Если вам интересны тесты скорости - погуглите. В наше время это не так и сложно.
lair
06.08.2021 18:53Высокая скорость работы обусловлена тем, что язык компилируемый, строго типизированный и позволяет передавать параметры функций на стеке.
Дельфи тут не одинок совершенно, не повод считать его самым быстрым, или даже "только он и cpp".
А, главное, в контексте реальных задач это часто не имеет значения (смотрите результаты тестов выше).
Если вам интересны тесты скорости — погуглите. В наше время это не так и сложно.
Так я погуглил, ничего не нашел.
1MK-Ultra
09.08.2021 10:38Производительность, да. И не только. Он во всём превосходит все новомодноые языки тип питона. Вот только заказчикам этого не обьяснить. Им нужен питон и точка. Никаких других доводов они и слышать не хотят. Спорить с ними бесполезно. Лучше под них приспособится, и зарабатывать деньги. Чем быть гордым но нищим разработчиком Delphi.
HemulGM
09.08.2021 14:30Если кто-то попросит крупный софт с GUI на питон я посмотрю, как ты будешь это делать
HemulGM
09.08.2021 17:40Да можешь хоть tkinter использовать. Только смысла в этом не будет от слова совсем.
1MK-Ultra
10.08.2021 08:58Насмешили. :) Браузер + сервер + движок на питоне. А вот сделать на delphi серверное приложение сможет не каждый.
lair
10.08.2021 11:29Он во всём превосходит все новомодноые языки тип питона.
Вот прямо вот во всем?
А C# вы тоже считаете новомодным языком, на всякий случай?
Вот только заказчикам этого не обьяснить. Им нужен питон и точка.
Ну, я могу их понять: у них есть набор требований по поддержке, куда может быть включен конкретный язык. Мало же найти того, кто софт разработает, надо еще иметь возможность найти кого-то другого, кто этот софт будет поддерживать.
1MK-Ultra
10.08.2021 16:22Для меня да. Суть не в новомодности. А суть в том что работодателей, ищущих программистов именно на Delphi очень мало. Питон я привел для примера. Пусть будет Java. Вот, (к примеру), упёрся заказчик, мне надо именно на яве. Никакие delphi мне не нужны.
lair
10.08.2021 16:24Для меня да.
Не, если для вас — то да, с этим сложно аргументированно спорить. Да и не нужно.
А суть в том что работодателей, ищущих программистов именно на Delphi очень мало.
Я выше уже предположил, почему такое может быть.
nmrulin
03.08.2021 01:33Ну не запросто. Времени уйдёт немало и непонятно на что.
Правда я в своё время разрабатывал автоматический транслятор в Си(без плюсов) для микроконтроллеров. Но там код требует иногда правки вручную, а чтобы 100% автоматически делалось, это требуется слишком много времени, да и мало кому нужно.
nmrulin
03.08.2021 01:28А на PascalAbc.net не пробовали откомпилировать?
belch84
03.08.2021 09:38Нет, не пробовал. Я об этом варианте Паскаля ничего и не знал, прочитал это и ужаснулся! Наверное, и не не буду пробовать
nmrulin
19.09.2021 23:30Ну с 2018 года там много глюк исправили. И уже и тогда эти глюки касались тех вещей, которые не были в Турбо Паскале. Его сейчас активно используют в школах, так что если бы были серьёзные проблемы с переносом программ, то это было бы широко известно. Поэтому если вы активно не собираетесь использовать "новые фичи", то всё должно работать.
DevDemi
22.07.2021 13:15Немного не в тему. У самого установлен Delphi 7, но честно забыл когда последний раз запускал. Буквально на днях вышла новая бесплатная версия: https://www.embarcadero.com/ru/products/delphi/starter
Уж очень быстро привыкаешь к хорошему и новым плюшкам.
Приходилось переносить свои старые проекты с 7-ки на 10.2 в среднем 1-2 дня работы (правда проекты не особо крупные).
ps О delphi 7 самые теплые воспоминания (студенчество).
third112 Автор
22.07.2021 14:31с 7-ки на 10.2 в среднем 1-2 дня работы
Сколько багов добавлял перенос?
DevDemi
22.07.2021 14:51Сейчас точно не вспомню, но минимум. Сторонних компонентов практически не было, GLScene попутно обновил до последней версии и все заработало.
Hlad
22.07.2021 13:58+2Попробуйте впихнуть в значимое имя фразу: загрузить из архивного файла, записи для товарных вагонов, расшифровать их, пустые вагоны добавить в таблицу свободных вагонов.
Забавно. У меня коллега тоже долго доказывал, что «в нормально читаемом коде комментарии не нужны». Ровно до тех пор, пока не пришлось писать ПО для микроконтроллера в специфическом устройстве. Ибо код, плотно завязанный на железо, получался абсолютно непонятным без комментариев, описывающих специфику этого самого железа. Так что когда кто-то говорит, что «в нормально читаемом коде комментарии не нужны» — это значит, что человек никогда не писал ПО для взаимодействия с чем-то аппаратным.
Tuwogaka
22.07.2021 14:01На данный момент Lazarus упомянут уже дважды, но так? что всё равно приходится спрашивать живого человека сидящего на Delphi 7 - ну почему не Lazarus?
third112 Автор
22.07.2021 14:06А он полностью совместим с Delphi 7? Т.е. любая прога на нем скомпилируется? А баги могут возникнуть при переносе?
Читаю вики:однако полной совместимости с Delphi нет
Tuwogaka
22.07.2021 14:23Понятия не имею, не пробовал дальше ЗдраМир. Рядом задал вопрос про Embarcadero, так оно выглядит неплохо, воспоминания детства освежает, но сайт по части как скачать и установить бестолковый крайне. А суть проста - инсталятор один, ориентируется по ключу, ключ приходит на почту.
raTaHoa
22.07.2021 21:51Если вы используете только стандартные оконные компоненты (заметьте что речь идет не о классах вроде 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
Alexey2005
22.07.2021 14:08+1Lazarus, к сожалению, довольно глючная штука. При работе с ним хорошо видно, что он состоит из отдельных компонентов, каждый из которых хорош, но друг с другом они стыкуются с изрядным трудом. Это не цельный продукт, а лоскутное одеяло, от которого постоянно что-то отваливается.
Tuwogaka
22.07.2021 14:13Очень может быть, я его запустил, заподозрил именно это, и убрал.
А Embarcadero Delphi Community Edition?
1MK-Ultra
22.07.2021 16:31Глюков не так много. Потом, если их знаеш, уже не возникает вопросов, просто обходиш их. Зато главное преимущество lazarus он GNU.
maximnik0q
22.07.2021 22:39+1Разная степень готовности компонентов -основной глюк.Я с одного сайта взял пример Солнышка-в винде все работает,в линуксе нечего не выводит.При этом кроссплатформенные компоненты и ошибок компиляции нет.....
1MK-Ultra
23.07.2021 16:12Я не использую компоненты. Только минимальный набор стандартных. Form, там button, memo, label, bitmap. Они работают без глюков. Мне всякие красивости и украшательства не нужны. Вот с базами там беда. То что отлично работало в delphi, иногда совсем не работает в lazarus. Приходится всякие подпорки ставить.
raTaHoa
22.07.2021 22:09+2Глюки версия от версии исправляются, особенно если люди о них сообщают сообществу лазаруса, или сами пишут "патч" и опять таки предлагают его внести сообществу лазаруса.
А вот что мне действительно не хватает в нем, так это такого же мощного отладчика, который был в 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)third112 Автор
22.07.2021 22:14Спасибо,
я, пожалуй, подожду с переходом, до той поры, когда будет хороший "дебагер".
kovserg
22.07.2021 14:03+1Мои научные интересы в основном принадлежат области математической (или, как еще называют — компьютерной) химии. Это применение теории графов к фундаментальным и прикладным задачам органической химии
К сожалению 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 то справка вновь будет работать.
Wolf4D
22.07.2021 15:27+2Как человек, прямо сейчас работающий на легаси средствах разработки - скажу, что проблема наступает, когда возникает необходимость в одном из трёх действий:
1) Присоединить к проекту другого программиста, или полностью передать проект ему.
Выглядит особенно грустно. Большинство программистов, увидев в 2021 году хотя бы 10-летнее легаси, начинает очень быстро пытаться или отгрести, или переписать код на современные рельсы, вынуждая Вас апгрейдиться. Я вот тоже недавно видел код на C++, где обработку ошибок кто-то реализовал на (привычных ему) longjmp-ах. Я вообще не знал, что на C++ так можно.
2) Портировать проект на ОС, где средства разработки и/или собранные ими программы живут уже с трудом.
Со временем появляется ОС, где старые наработки не живут, или живут плохо. Хотя недавно я открывал свою старую игрушку на Visual Basic 6 - и хех, под Win10 она до сих пор работает.
А вот часть библиотек, используемых в другом проекте, уже работают даже под Win7 некорректно.
3) Добавить в проект поддержку новой библиотеки, которая не имеет точек входа, запросто доступных для Ваших средств разработки.
Печальная правда. Поддержка старых версий и стандартов отваливается, документация исчезает, знания рассеиваются. Для любого следующего действия приходится заниматься прикладной палеонтологией.
1MK-Ultra
22.07.2021 17:01Пришол в организацию, где работают с программами написанными на клиппере. Если windows x64, запустить их там большие проблемы. Что то исправлять приходится очень долго. Основная часть веремени уходит на поиск того, где это. Потом долго думаеш как оно работает. А исправить 3 минуты.
maximnik0q
23.07.2021 01:18>Если windows x64,
А что там с проектом http://www.harbour-project.org/ ,не слежу и не занимаюсь клиппером,просто интересно.Я давно слышал что там портировали на linux и даже у народа есть интересные проекты.
1MK-Ultra
23.07.2021 16:19Дык и я не следил и не занимался. В 90-ых последний раз с клиппером работал. Теперь пришлось вспоминать. Собственно меня для этого и наняли, чтобы всё переделать на современные платформы. Особой радости мне это не доставляет. Но деньги то нужны.
numitus2
22.07.2021 15:58Тут есть 2 варианта. Либо выкидывать все, либо переписывать на что-то по-актуальнее. Все равно через 15 лет это станет невозможно поддерживать
PavelBelyaev
25.07.2021 04:38+2Мне кажется новичкам и сейчас актуально писать начинать на паскале, тот который ABS вполне норм работает на актуальной винде. Достаточно просто хэлоуворды писать и алгоритмизацию учить и при этом строгая типизация.
unsignedchar
25.07.2021 08:09Если новичок планирует получать какие то ₽₽₽ или $$$ - неплохо посмотреть на вакансии и зарплаты.
nmrulin
03.08.2021 01:13Надо сначала определиться, подходит ли человеку программирование вообще, а не вакансии смотреть. Так бы люди ничего никогда не учили, если бы сразу заботились о том, а чем пользуются профессионалы.
raTaHoa
25.07.2021 15:38Вот, что-что, а PascalABC вообще к паскалю только внешней схожестью относиться, работает совершенно иначе, вдобавок имеет намешку от .NET, и совершенно не годиться для написания чего-то серьезного.
А еще много чего на нем работает не так как должно. Приходилось как-то помогать писать студенческое приложение для решения простенькой задачи, написал за минут 10, проверел в нормальной среде (для Lazarus и Delphi этот код работал без проблем, более того этот код работал бы и на TurboPascal), но как выяснилось этот код был совершенно неработоспособен в PascalABC, пришлось ставить это чудо и смотреть, что же ему не нравилось, после целого дня возни и экспериментов, выяснилось, что он иначе строит структуру строк, и если дополнительно не приклеивать некоторые символы в конце, то стандартные методы WRITELN начинали падать, как и странно работал READLN, захватывая в строку лишние символы. Возможно с того времени это уже исправили, но все равно многие вещи которым обучают на нем, работают только на нем.
Лучше уж на Lazarus, так же бесплатно и современно, и без лишних примесей, и кроссплатформенно, и вполне можно писать что-то серьезное, начиная от простых десктопных программ, полноценных игр, и заканчивая многопроцессорными комплексными приложениями, или приложениями с высокой нагрузкой и сложной структурой данных.И все это так же из коробки после установки.
При желании даже CGI-приложения можно легко написать, или мобильное приложение создать (хотя это немного сложнее, так как требует отдельной возни с компилятором).
nmrulin
03.08.2021 01:22В Delphi обычно несовместимость при переходе на более новые версии из-за компонентов. Однако для многих из них всё-таки аналоги есть.
Я по опыту помню переход в 7 на 2006 запомнился тем, что надо было взять новый компонент СPort. В Delphi 2010 появился Юникод + опять менять СPort. В XE2 , опять менять СPort. При переходе на XE7 и 10 и вспомнить-то особо нечего. В основном просто старый код работал в новой среде.
А обновлять надо, т.к. ещё в XE7 программы на Андройд работают косорыло, тот же USB у меня так и не заработал, а на 10 всё нормально. Так что кросплатформенный код сейчас требует обновления. Если только для Windows , то да, можно десятилетия ничего не менять.
third112 Автор
14.08.2021 01:24Не ожидал, что будет столько отзывов!
Всем спасибо!
Скажу: нтересно, если Паскаль возродится, а мне возразят, что не умирал ;)
IvanEjik
16.08.2021 14:08+1Шикарная статья.Меня самого в принципе устраивал D7 до недавнего времени.
Только у него очень медленная сборка больших,да и средних проектов тоже.
А когда я полез смотреть алгоритмы обработки видео/изображений то тут пришлось переходить на новую(старую XE4) ради вменяемой многопоточности.
Да тоже простейшее распознавание образов на D7 к сожалению не проверить именно на "скорость" отработки алгоритмов в параллельном исполнении.
А так использую постоянно,самая шустрая среда для быстрых тестов.
И да, паскаль не умирал :)third112 Автор
16.08.2021 14:32Спасибо.
устраивал D7 до недавнего времени.
Только у него очень медленная сборка больших, да и средних проектов тоже.
[...]
Да тоже простейшее распознавание образов на D7 к сожалению не проверить именно на "скорость"М.б. проекты запредельного объема, которые в любой IDE будут тормозить. Модульность, COM и т.д. в помощь. Я использовал распознавание на OpenCV в не самом простом проекте. Компилировалось очень быстро — не мерял доли секунды.
Интересно, что интерпретатор Pascal P5 на D7 быстро работает.
Действительно:
И да, паскаль не умирал :)
third112 Автор
16.08.2021 14:45Про многопоточность. В начале 2000х участвовал в международном конкурсе-марафоне Intel, на многопоточность. Занимал 5 место используя D7. Мой код по скорости не уступал коду на C++, но за использование Intel Threading Building Blocks начисляли доп. очки. Были участники и со своим компилятором C++.
IvanEjik
16.08.2021 14:59Занимал 5 место используя D7.
Знаю что там нет большого преимущества у С++.
Я имел в виду удобную прикладную многопоточность(когда отдал всё на обработку в TreadPool и быстро посмотрел результат) а в 7 Дельфи нужно посидеть и написать свои классы и обёртки для системных потоков(если не имеется подобных наработок заранее).
IvanEjik
16.08.2021 14:48Я не знаю что за трабл такой но сборка 24000 строк кода в D7 у меня занимала несколько минут.Очень медленно именно GDIOBJ.pas и GDIPAPI...
К слову в новой IDE(XE4) это за 0,3 сек происходит.
Я не вникал почему так,возможно экономия памяти,а возможно что компилятор однопоточный.
Диск SSD 1Tb Samsung Evo Plus один из самых быстрых NVME третьего поколения PCI_E.Оперативной памяти больше чем нужно (128Гб).Процессор 12 ядер/24 потока хватает для любых задач,хоть линукс собрать из исходников.
Вот ради теста пересобрал опять,время на скриншоте.
https://ibb.co/N9QMd9vthird112 Автор
16.08.2021 15:09Очень странный трабл! Примерно 24000 строк исх. кода компилятора у меня даже на ЕС ЭВМ (OS 360/370, Pascal 800/2.0 из Австралии) быстро транслировались. ИМХО 24000 строк — не крупный проект. М.б. из-за warnings?
IvanEjik
16.08.2021 15:17Я использовал распознавание на OpenCV
У меня не получилось подключить CV...Хотя пробовал раза три.
В итоге переписал нужные функции оттуда полностью на паскале,например поиск границ,поиск шаблона,фильтрацию MeanShift,кучу других фильтров..K-means например.сейчас пишу сегментацию разрастанием регионов.Свой код иметь удобнее,полный контроль и понимание происходящего :)third112 Автор
16.08.2021 15:37Кроме уже упомянутой OpenCV использованы библиотеки Delphi-OpenCV (Laentir Valetov, Mikhail Grigorev)
Свой код, безусловно, удобен, но это лишнее время и силы.
IvanEjik
16.08.2021 16:01Спасибо.
Но уже не буду :) У меня есть почти все основные функции.
Я начал так сказать личный челлендж по "переписыванию" OpenCV на Паскаль, только с паскалевскими типами данных .завершено ~15%.Есть начало реализации SIFT/SURF/FAST/ORB(пока читаю документы) .
Даже не знаю во что это в итоге выльется...Разработчики Делфи давно обещали поддержку AVX2,но так и не сделали даже в новых версиях,аргументируя что есть более важные задачи у них.А ведь это основа обработки больших массивов данных,например в видео потоке или распознавании....В любом случае весь мой код пока он маленький работает и на D5,D7 и на XE4 и на Rio 10.4.2.third112 Автор
16.08.2021 16:27В CV много не сделано, и Вам хватит работы на много лет. Так совпадение с шаблоном-картинкой зависит от ориентации, и мне пришлось использовать 8 тестов на совпадение. Была переписка с разработчиками — они честно признали, что недоработка.
Разработчики Делфи давно обещали поддержку AVX2, но так и не сделали
Интересно, а асм-заплатки тут будут работать или только inline?
IvanEjik
16.08.2021 16:38В CV много не сделано, и Вам хватит работы на много лет Так совпадение с шаблоном-картинкой зависит от ориентации
Уже три года пишу :)
В опенЦв может и зависит :) У меня нет.
Я же не тупо копирую,а пишу СВОЙ код исходя из потребностей,но на примере кода OpenCV.
Про инлайн столько споров...Раньше он вызывал рост размера приложения.
А про асм вроде вставки в процедуры/функции уже давно запретили.
Осталась возможность писать лишь целиком функцию на ассемблере.third112 Автор
16.08.2021 17:13Желаю успехов!
Будет очень интересно опробовать Ваш код — сообщите, пожалуйста, когда будет готов.Про асм запретили — это одна из причин, что не использую новые версии Делфи. У меня много старого кода, где асм.
forever_live
16.08.2021 18:59Никто asm-вставки не запрещал. По крайней мере, для Win32.Попробовал только что в D10.3.
P. S. Вот для других платформ asm не поддерживается.
forever_live
16.08.2021 19:21На данный момент проекты на несколько миллионов строк и тысяч файлов — вовсе не запредельны для коммерческих продуктов. На одном из таких когда-то использовалась D4, и она перестала справляться. Фризы, сбои при инкрементной компиляции, вот это всё. Бизнес был вынужден дать добро на переход на версию поновее. Новая IDE заработала ощутимо живее, и многие детские проблемы старой версии ушли.
mSnus
Грустная история, на самом деле. История о полезном коде, который надо бы транслировать подо что-то современное, но для этого надо выучить ещё и это капризное современное.
И тот полезный код превращается в чемодан без ручки -- тащить неудобно, а выкинуть жалко.
Так досадно, что так и не появилось надёжных средств автоматической миграции с D7 куда-нибудь в RAD Studio! Вот не понимаю, это такая сложная задача, или просто сообщество уже вымерло и никому это неинтересно?
third112 Автор
Кобол и фортран старше, но они живы.
mSnus
Они не являлись "языком одной корпорации"
Error1024
А Object Pascal когда стал таким языком? Из того что активно развивается сейчас: минимум 2 свободных и 2 коммерческих реализации сразу на ум приходят.
third112 Автор
Первый ОО Pascal Борланда был турбо 5.5. MS в это же время выпустил свой (названия не помню). Продукты столкнулись. В Byte-en про это большую статью напечатали. Борландовский победил. А У.Гейтс очень обиделся на Pascal.
Severn
У MS был Quick Pascal.
И вроде после появления TP 5.5, максимум 6.0, Microsoft из этой гонки вышел.
Bwana
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, было реализовано кривейшим образом, либо вообще никак.
demon416nds
В 90% случаев с d7 можно безболезненно мигрировать на Lazarus, совместимость куда выше чем с новыми версиями radstudio
DrPass
Тут скорее не появилось желания мигрировать у автора. Помнится, мы лет двенадцать назад переводили кучу проектов с Delphi 6 на Rad Studio 2007 и в общем-то оно заняло пару дней с минимумом правок. В том числе и плагины самой IDE («эксперты», как их там называли)
third112 Автор
Зависит от кол-ва накопленного кода: своего и чужого.
pulk
Тоже доводилось лет 10 назад перетаскивать проект с Delphi 7 на актуальную тогда RAD Studio. Выездная сессия, команда из 10 человек, 2 недели. Проект был на 10 миллионов строк кода.
third112 Автор
У меня нет столько грамотных людей, чтобы перетащили мои личные архивы.
pulk
А сколько там строк?
third112 Автор
У меня 4 винта по 1Гб, но там не только коды, но по несколько ОС, и тексты статей и инструкций. + много DVD. Много дублируется. Многое сжато. Надо месяцами разбирать, что переносить. Я храню промежуточные версии. Для переноса надо чистить мусор и тестировать полученный перенос — это задача не одного года.
kosmonaFFFt
А системами контроля версий, типа git или mercurial не пробовали пользоваться? Я для себя mercurial открыл больше десяти лет назад, и все личные проекты долго в нем версионировал.
third112 Автор
Я не знаю, что произойдет с ними через несколько лет. Одно время я писал и обсуждал в ру-блоге ISN. А потом они все потерли.
unsignedchar
Локальный git/mercurial никто, кроме вас, не потрёт.
third112 Автор
Сейчас — да. А что м.б. через несколько лет никто не знает. ИМХО история DEC очень поучительна.
lair
А что может случиться через несколько лет с репозиторием, который представляет собой папку в вашей файловой системе, чего не может случиться с любой другой папкой в вашей файловой системе?
third112 Автор
Зачем мне системама контроля версий? Проги с оригинальными алгоритмами храню с первой версии. Т.к. и она может оказаться нужной. Пройдет время и вылезет пропущенный баг. Возникнет вопрос на какой версии он был пропущен? М.б. в первой этого бага не было и он завелся в результате следующих изменений.
usrsse2
Так команда
git bisectименно эту задачу автоматизирует.third112 Автор
Бывают случаи, когда человек правит код и его отвлекают — и он попал по клавише не в том месте — выражение изменилось — вместо плюса минус. Но последущие тесты и работы с прогой этого места не коснулись. В таком случае стоит глянуть правильно ли работает это место в первых версиях.
Как тут поможет git bisect?
0xd34df00d
Здесь вам даже
git bisectне нужен. Вы просто делаетеgit checkout тэг-первой-версиии прогоняете свои тесты там. Вот если там всё работает, и если вы хотите найти место, где всё сломалось, то вы начинаете бисект, помечаете первую версию как хорошую,HEADкак плохую, и либо прогоняете логарифмическое от количества ревизий количество тестов, либо пишете скриптик, который запускает нужный тест и возвращает его статус, иgit bisectнаходит вам плохой коммит сам.khajiit
А тут поможет банальный просмотр изменений перед коммитом, который, например, показывает
sublime merge. Вы увидите во-первых, файлы, в которых произошли изменения, во-вторых, сможете хоть построчно эти изменения принять/откатить до того, как ваша работа уйдет в коммит.Все cvs разных сортов автоматизируют утомительную ручную работу с
find,diff,cp,patchи другими утилитами, которые можно использовать для того же самого, хранят историю, позволяют вести работу в нескольких ветках над одним и тем же кодом, обмениваться сделанной работой, и все это без облаков и сетевых служб.0xd34df00d
Система контроля версий для этого отлично помогает, см.
git bisect.Я даже свои локальные проекты все храню в локальном гите просто потому, что это удобнее.
lair
Ровно для того, чтобы иметь доступ ко всем версиям и их истории, как и любому другому разработчику.
Вот как раз в этом случае СКВ прекрасно помогает: переключились на первую версию, увидели весь код, как был.
git bisect, как вам уже не раз написали.unsignedchar
Я так понимаю, вы путаете git (программу) и GitHub (облачный сервис).
third112 Автор
Читаю в Вики:
Я и решил, что Вы мне облако советуете. А с версиями (локально) у меня обычно нет проблем, но мусор, если нужно предпочитаю разгребать руками.
unsignedchar
Специальная программа для незаведения мусора типа my_program_YYYYMMDD_final_2_fixed_3.arj с этим справится ещё лучше ;) А если рабочих мест >1, мусора возникает ещё больше.
Рекомендую таки попробовать. Денег за это не берут, все что нужно - время от времени запускать tortoise hg и нажимать кнопку commit.
third112 Автор
Спасибо,
попробую. Но в общем придерживаюсь принципа KISS («Keep it simple, stupid»). Если легко могу без чего-то обойтись, то режу бритвой Оккама.
tenzink
C git/mercurial ничего не случится. Это системы контроля версий. Репозиторий хранится локально. От потери данных сам по себе не спасёт (нужны бекапы и т.п.), но от кучи дубликатов вполне может помочь
third112 Автор
Опечатка: не 1Гб, а 1000Гб. Отвлекли при наборе. Приношу извинения.
mSnus
Когда я в последний раз интересовался этой темой, мне советовали поэтапно переводить через каждую следующую версию, этапов в 5. Надо попробовать ваш рецепт..
geher
Переход с версии на версию Delphi/Rad studio достаточно прост, но может быть все-таки сильно осложнен двумя проблемами.
Первая и часто почти непреодолимая - сторонние компоненты, заточенные под определенную версию. Часто без исходных кодов и без развития с вариантами под новые версии среды разработки.
Вторая легко преодолима, но очень трудозатратная - строки. К счастью, проблема проявляется только один раз в жизни проекта. Был там момент перехода на уникод, для перехода через который приходилось очень много переделывать с этими самыми строками.
Остальное там достаточно просто решаемо.
Error1024
А нет никаких проблем миграции, кроме строк ставших юникодными(WideString), впрочем возможность поменять string на AnsiString там, где Юникод не применим — есть. Есть примеры проектов на сотни тысяч строк кода, которые «мигрировали» на последнии версии Delphi за несколько дней.
Автору можно посоветовать: попробовать бесплатную Delphi Community Edition, новая версия которой вышла буквально вчера. Либо Lazarus, где UI по умолчанию очень привычен для пользователя Delphi 7, однако это современная IDE, с современным компилятором FreePascal и работающая везде, в том числе под Linux.
gatoazul
Это "современное" устаревает со страшной силой и супермодное уже через пару лет выглядит смешным. Паскаль как мертвый язык хотя бы не меняется.
HemulGM
Delphi меняется
khajiit
FPC не спасет аксакалов?