Pull to refresh

Comments 43

UFO just landed and posted this here
Мне нужен. И многим другим.
Лысым например расческа не нужна, а балерине отбойный молоток.
В данный момент судьба делфей — саппорт старых проектов. Пусть так и будет, не пинайте труп.
Вот потому-то и нужен, что проект хоть и старый, но развивается дальше.
простите конечно, но он не развивается, а разлагается… Если вы продолжаете его поддерживать на Delphi…
А в чём конкретно это выражается?
Естественно, с точки зрения пользователей. Мы же софт не для себя пишем…
С точки конечного пользователя это может кончится точкой когда приложение перестанет работать в том окружении которое ему нужно. А скорость переноса может быть недостаточной. на пальцах поясню язык скажем так не очень хорошо и резворазвивается, может наступить тупик его поддержки ОС(в данном случае это windows) как это было с например assembler(согласен пример не самый удачный). Соответственно есть вероятность оказаться в этом тупике. Но пользователю будет невдомек, ему будет хотется чтобы «все работало».
Экстрасенс на выезде предсказывает будущее.

Забота о пользователе — дело программиста. Как позаботишься так и будет — нет разницы какая IDE или язык использован в приложении.
Майкрософт не сумашедшие чтобы отказываться от поддержки Win32. На хабре даже топики были про их команды, которые занимаются тестированием совместимости программ с новыми версиями винды.
Тот же TotalCommander написан вроде на Delphi 2 и до сих пор работает.
И если этот «тупик» настанет, то случится это не раньше чем сама винда будет переписана на .NET, т.е. случится это явно в отдалённом будущем. Одновременно должно случится так, что Embarcadero похоронит к тому времени Delphi окончательно.
Поэтому не вижу реальных причин перехода на .NET. Я предпочитаю развиваться вширь и изучать например Python/Django. Пользы от этого намного больше, особенно учитывая тенденцию смешения в web сервисы.
Гм а причем тут Win32? Речь идет в основном о библиотеках которые под Delphi подложены, если них поменять API, а команда Delphi не сделает фикс как бы весь Delphi развалится, говорю опятьже идеалогически, ибо то как устроен и работает компилятор Delphi помню уже очень смутно… В общем-то речь вечл именно об этом, впрочем меня эти вопросы равно как и вопросы .net затрагивают очень отдаленно…
При том что Delphi использует Win32 API, а не тот же .NET.
А сам API вообще то не изменяется, разве что развивается (обратная совместимость, однако). Единственно что бывает, это добавляю более строгие проверки, но это уже проблема криворуких программистов.
А если и случится, то изменить описание API функции можно хоть в Delphi 1 и всё будет опять нормально работать. Все исходники же есть, да и переопределить функцию только для своей программы это 1 строчка.
Т.ч. это абсолютно не аргумент.
>А сам API вообще то не изменяется, разве что развивается
Уверенность в завтрашнем дне просто поражает

>А если и случится, то изменить описание API функции можно хоть в Delphi 1 и всё будет опять нормально работать.
Вот тут вообще ничего сказать не могу, в силу опятьже не очень глубоких знаний о том как Delphi устроен изнутри. Если он такой замечательный и гибкий, чтож значит будет процветать и дальше…
Такая вот строчка описывает функцию API:

function GetFileAttributes(lpFileName: PChar): Integer; stdcall; external 'kernel32.dll' name 'GetFileAttributesW';

Если MS надо что то изменить, то она создаёт новую функцию с префиксом Ex или предусматривает заранее параметры в существующей, т.е. на текущую реализацию это не влияет. Обратную совместимость никто не отменял, на этом уверенность в части проблем с API и строится.
Неужели в .NET MS от версии к версии стала изменять определения функций?
расскажите зачем он вам нужен и чем обусловлен выбор платформы?
Для разработки ПО и Досталось в наследство.
Delphi 2010 точно никому не нужен, если Bам нужно перейти с Deplhi 7(и прочие) на новую Delphi(2010) — с Вами что то не так…

Delphi 7 — да — все еще актуален в силу необходимости поддержки софта…
В Delphi XE уже достаточно поддержки Unicode и полноценной работы среды в Win7 x64.
Не стану же я переписывать десятки тысяч строк кода на тормознутый .NET, а c++ по сути тоже самое, только тоже самое делается дольше (к сожалению, вынужден пользоваться для написания 64-битных расширений).
С Visual C++ работаю не очень плотно, но каких то особых приемуществ среды не вижу, что то лучше сделано в Delphi, что то в Visual Studio. Точнее для меня единственное преимущество Visual Studio в том, что глюков меньше.
«тормознутый .NET» быстр в разработке и доработке. Хоть исходники теряй — все-равно можно продолжить разработку.
Я недавно с удивлением обнаружил что у меня стоит одна .NET программа. А я ещё удивлялся, что же это она так медленно запускается и отображается для простого функционала на моём Core i5 (KeePass).
Я просто занимаюсь шароварой и поэтому у меня приоритет скорости работы на компах пользователей, а не в разработке, да и сам фреймворк заставлять ставить не надо.
В Delphi тоже можно без исходников работать (dcu файлы), а вообще надо сохранять копии проектов, чтобы не терять исходники.
Тормознутость приложения обусловлена радиусом кривизны рук разработчика, а также расстоянием плечевых суставов от тазобедренных. Наверное удивлю вас, но говнокодить можно на любом языке под любую платформу.
Я согласен конечно, но на данный момент всё выглядит так (я делаю вывод на основе всех встречанных мной программ на .NET), что необходимо прикладывать больше усилий для оптимизации кода на .NET, что вероятно нивелирует приемущества увеличения скорости разработки.
Проблема C# в том, что у этого языка очень низкий порог вхождения, и как следствие, соотношение приложений написанных хорошо и приложений написанных кое-как, значительно хуже, чем, например для C++. При желании на C# любой школьник сможет написать программу, напоминающую работоспособную. А вот на C++ у школьника скорее получится «FUUUUUU...» чем работающее приложение.
Однако при этом, чтобы писать на C# хороший код, нужен суммарный объём знаний, превышающий таковой, например, для того-же C++. Это обусловлено тем, что помимо нативных концепций нужно знать еще и особенности .NET CLR'а.
Проще говоря, очень легко заставить .NET выполнять избыточный код, выполняющий много лишних операций. Так что тут дело опыта.
Негативное отношение к Delphi программам появилось точно так же, от низкого порога вхождения. А сейчас MS создало своё Delphi :)
Когда я впервые начал программировать, сторонники плюсов приводили тормознутость дельфи как аргумент, а дельфисты скорость разработки считали преимуществом. Куда катится этот мир (
А на современных компах скорость работы Delphi и C++ уже не принципиально отличается на большинстве типовых задач. Конечно, если нужна экстремальная производительность, то C, конечно, предпочтительнее.
А вот скорость разработки в C++ не увеличилась.
А вы пользовались Delphi когда-нибудь сами?
UFO just landed and posted this here
UFO just landed and posted this here
немного пиара и делфи снова будет нужен
Сразу возникает желание писать так:
MinimumAttribute<T: IComparable> = class(BaseValidationAttribute)
public
constructor Create(MinimumValue: T; const FailureMessage: string);



[Minimum(18, 'Must be at least 18 years old')]
property Age: Integer read FAge write FAge;

но как я понимаю — такое в Delphi не получится?
Получиться. Применяешь дженерики и все тоже самое будет.
IComparable есть с Delphi 2009
это просто отлично. пора переводить проекты с D7
Если убрать то, что в квадратных скобках, то вот оно. Сразу и не понял, что ваш код как бы не делфи.
[Minimum(18, 'Must be at least 18 years old')]
property Age: Integer read FAge write FAge;

в чем вообще смысл вводить свойство в данном случае? ни геттера, ни сеттера нет ведь; а если сеттер есть — так там какие угодно проверки делать можно…
Сам себе и ответил — вот тебе и смысл: проверка настолько проста, что введение методов Get/Set это излишество, если ты просто задаешь для разных свойств диапазон значений.

При большом числе таких свойств сократиться избыточность кода.
Суть в наличии дополнительной мета-информации и чистоте доменной модели. Атрибут можно считать в run-time и сгенерить, к примеру, js-код для валидации на клиенте. Или в случае с desktop софтом, то сгенерить форму с автоматической валидацией. Или нагенерить какой-либо код — хоть SQL код для создания триггеров с проверками валидности данных в базе данных.

А свойства с точки зрения ООП лучше создавать всегда, чтобы потом не перелопачивать весь код — иногда требуется кинуть события при изменении данных, или совершать какие-то дополнительные, изначально не предусмотренные действия.
Блин, я как вспомнил слово Дельфи, целый пласт жизни прошел перед глазами. И настроение поползо вверх.
Ох, даже полез на трекер искать где бы скачать 2010 версию.
уже Delphi XE вышла, постабильнее будет :)
А как там с лицензимя? Есть что то типа экспресс версии?
Нет, больше нет. В прошлый раз у них продажи резко просели, т.ч. больше они не планируют бесплатных версий.
Спасибо уже читаю, поставлю триал, попробую сделать свои задачи если получиться, то может куплю. Все таки 27 тыщ _в_приниципе_не так уж и много.
Для всех скептиков, а также не разбирающихся и вообще не знающих что такое Delphi.
Времена CodeGear прошли. Это действительно был застой, стоит сказать, что .net еле еле поддерживалась 2.0. Очень странная ценовая политика. Разработчики просто стали уходить. Но теперь Delphi владеет Embarcadero. За очень короткий период времени они подтянули .net до текущей версии. И видно взялись за популяризацию.
Пока все видится очень перспективно. Можно сказать, что сейчас мы все свидетели второго рождения Delphi. Будет очень интересно наблюдать за проектом в ближайшие годы.
Sign up to leave a comment.

Articles