Comments 84
А я надеюсь что будет и у них какое-то движение в сторону open-source. Все-же корпорация+сообщество лучше чем просто корпорация.
компанией Idera, специализирующейся на инструментах для баз данных
Ну вот и отдали бы саму среду в OpenSource. В дар сообществу Lazarus/FPC, например.
И дальше специализировались на своих инструментах )))
Эх, мечты-мечты…
А что например мешает открыть общие средства разработки (ту же VCL) под какой-нибудь BSD лицензией? Наверняка нашлись бы желающие портировать под Linux и OSX (хотя под OSX у них вроде что-то есть… но я давно уже не отслеживаю: ).
Среду разработки было бы тоже очень неплохо, по старой памяти среда-то была неплохая. Тем более что они в процессе перехода на открытый Clang, вот бы и Дельфи перевели на LLVM заодно. Хотя может и старый компилятор кого-нибудь заинтересовал бы, чем больше компиляторов тем лучше.
Оставили бы платными специальные вещи типа работы с коммерческими СУБД, ну и корпоративную поддержку. Сейчас, когда есть Qt, Java, C# и все это фактически бесплатно, требовать с разработчиков такие суммы денег странно:)
Среду разработки было бы тоже очень неплохо, по старой памяти среда-то была неплохая. Тем более что они в процессе перехода на открытый Clang, вот бы и Дельфи перевели на LLVM заодно. Хотя может и старый компилятор кого-нибудь заинтересовал бы, чем больше компиляторов тем лучше.
Оставили бы платными специальные вещи типа работы с коммерческими СУБД, ну и корпоративную поддержку. Сейчас, когда есть Qt, Java, C# и все это фактически бесплатно, требовать с разработчиков такие суммы денег странно:)
Стоит компании набрать обороты и начать выпускать качественный продукт, как ее продают кому-нибудь.
Хмм, подозреваю, что следствие и причина могут будет ровно противоположенные: как только компанию собираются продать кому-нибудь, ей дают достаточно средств и ресурсов, чтобы она создала видимость набора оборотов и выпуска качественных продуктов, так как покупают не реальное положение дел в компании, а «видимость» компании со стороны. Поэтому предпродажную подготовку делают не только машинам, но и компаниям (за год-другой до сделки).
Пугает не известность. Очень жаль если похоронят такой замечательный продукт
А он действительно такой замечательный, или это просто остатки впечатлений молодости?
намёк: «впечатления молодости» могут быть и отрицательными и нейтральными.
А для меня Делфи это как Ардуино, ничего крупного на ней не сделаешь, но всякую одноразовую мелочь делать можно очень быстро. Т.е. просто штука которая неплоха в очень узком диапазоне задач.
А для меня Делфи это как Ардуино, ничего крупного на ней не сделаешь, но всякую одноразовую мелочь делать можно очень быстро. Т.е. просто штука которая неплоха в очень узком диапазоне задач.
Причем тут молодость, на Delphi делаются и крупные проекты, все прекрасно работает и летает, дело в руках, кто делает. Можно и на Си шарпе сделать школьную поделку.
То что сейчас он стал не популярен это как раз из за подобных заявлений.
То что сейчас он стал не популярен это как раз из за подобных заявлений.
ключевая фраза была "А для меня ", потому что крупные проекты я делаю для МК.
Да не спорю мужики, но под МК делфи пока не может, особенно например под 8 битные.
Да не спорю мужики, но под МК делфи пока не может, особенно например под 8 битные.
Руки у меня чешутся отправить вам одну «поделку». Если один человек работает с одним проектом, то работать худо-бедно можно. Когда разработчиков становится больше одного, а разрабатываемых модулей — несколько десятков, в дело вступает квантовая механика.
Это на делфи-3 сложно было сделать что-то крупное, современная делфи сильно продвинулась в этом.
С Ардуино можно сравнить какой-нибудь жава-скрипт…
С Ардуино можно сравнить какой-нибудь жава-скрипт…
С Дельфи-3 и берут свое начало многие корпоративные разработки. Если правильно помню, то именно в этой версии была расширена работа с клиент-серверными технологиями, введена поддержка 3-хзвенки и отдельный TClientDataset, позволяющий использовать XML-данные. Из минусов стало то, что в отличии от Дельфи-2 изменлся формат PE-файлов и стало не возможно на ней создавати штуки для системы — дрйвера и пр.
Как можно сравнивать не сравнимое, типа Arduino и JavaScript? Это примерно так же, как сравнивать арбузы и девушек между собой. Если ужи хотите «опустить» Ардуино-фреймворк (а не само железо), то хотяб сравните с разработкой на чистом avr-gcc.
Как можно сравнивать не сравнимое, типа Arduino и JavaScript? Это примерно так же, как сравнивать арбузы и девушек между собой. Если ужи хотите «опустить» Ардуино-фреймворк (а не само железо), то хотяб сравните с разработкой на чистом avr-gcc.
Они хоть и начинались, но 3-я все-таки была больше для студентов. Те корпоративные разработки что начались на 3-й быстро перешли на 5-ю.
Вот с 5-й делфи пожалуй и началась нормальная корпоративная история.
Я их застал. У нас досихпор проект на 5-й делфи в поддержке-допиливании.
А ардуино и делфи сравнивать можно? речь шла именно об этом сравнении, В программировании сравнить с ардуино по концепции и форме можно именно джава-скрипт, а паскаль в делфийской интерпретации остается все же более низкоуровневым языком.
Почему-то о легкости языка судят по тому как быстро можно нарисовать формочки… но ведь это всего лишь банальная автоматизация рутинной работы.
Вот с 5-й делфи пожалуй и началась нормальная корпоративная история.
Я их застал. У нас досихпор проект на 5-й делфи в поддержке-допиливании.
А ардуино и делфи сравнивать можно? речь шла именно об этом сравнении, В программировании сравнить с ардуино по концепции и форме можно именно джава-скрипт, а паскаль в делфийской интерпретации остается все же более низкоуровневым языком.
Почему-то о легкости языка судят по тому как быстро можно нарисовать формочки… но ведь это всего лишь банальная автоматизация рутинной работы.
То есть Total Commander, Nero Burning Rom, WinRAR, NuSphere PhpEd и другие — недостаточно «крупные» проекты по вашему?
С WinRAR гражданин хватил лишку, оно очень даже MSVC. Остальные вроде как да.
Кстати, почему плагины в Тотал Коммандере построены по технологии dll, а не bpl?
А зачем bpl? Когда я делал систему плагинов у себя, я в сторону bpl и не думал. Даже не сказать чтобы очень представляю как удобно можно было бы их использовать. А главное писать :)
Технически, это то же самое. Только bpl во первых нестандартная, плагины писать можно было бы только на делфи, а во вторых очень зависима от версии компилятора. И приложение и плагин должны быть скомпилированы одной версией, иначе будут проблемы совместимости.
bpl-ки у нас используются там где много разных приложений(модулей) в рамках одной общей экосистемы собираемой одним компилятором.
bpl-ки у нас используются там где много разных приложений(модулей) в рамках одной общей экосистемы собираемой одним компилятором.
Увы, в bpl есть одно важное преимущество — они совместимы с… bpl. С кучей пакетов, в которых лежит куча компонентов, которые обычно используются в программах. Если вы положите форму в длл, то вам придётся впихнуть в неё все юниты из VCL, которые используются плагином, или как-то извращаться, чтобы использовать bpl-ки. C bpl в качестве плагинов это гораздо проще сделать.
И второй фактор — длл практически невозможно гарантированно деинициализировать при выгрузке. Для моего проекта это означает, что как бы не был хорошо спроектирован главный модуль, ошибок не избежать, любой сторонний модуль способен положить программу.
Вопрос изначально состоял в том, почему bpl настолько ущербен и налагает столько ограничений.
И второй фактор — длл практически невозможно гарантированно деинициализировать при выгрузке. Для моего проекта это означает, что как бы не был хорошо спроектирован главный модуль, ошибок не избежать, любой сторонний модуль способен положить программу.
Вопрос изначально состоял в том, почему bpl настолько ущербен и налагает столько ограничений.
Вот о чем и речь. Зачем это нужно? :) Длл лишена этих недостатков.
Для больших проектов, для внутреннего использования.
В DLL мы вынуждены таскать всё необходимое с собой. А теперь представь какое дублирование кода будет в проекте в котором сотня таких независимых модулей.
В DLL мы вынуждены таскать всё необходимое с собой. А теперь представь какое дублирование кода будет в проекте в котором сотня таких независимых модулей.
Ну я в длл никогда не сувал формы. Поэтому в моём случае это было более чем оправданно. Мои dll с доп функционалом были по 10-30Кб весом.
Тут всё от случая зависит, где-то и придётся заниматься извращениями с bpl, но в целом для таких целей была dll придумана.
Тут всё от случая зависит, где-то и придётся заниматься извращениями с bpl, но в целом для таких целей была dll придумана.
Кроме форм и компонентов есть еще много вещей которые пихаются в DLL-ку поскольку неизвестно с каким приложением её будут использовать — например менеджер памяти, процедуры, константы и функции из модуля SYSTEM и т.д. для банального округления числа при вычислениях приходится тянуть туда же Sysutils, Math…
Если понадеяться на то что у приложения будут необходимые функции то появляется проблема совместимости разных версий этих функций, особенно если в них реализовано разное поведение(или известные баги). Тут тоже не всё так гладко как хотелось бы, и применение bpl в проекте delphi-only более предпочтительно чем dll.
Применение dll в проекте на делфи оправдано только если этот модуль может быть использован в стороннем приложении.
Если понадеяться на то что у приложения будут необходимые функции то появляется проблема совместимости разных версий этих функций, особенно если в них реализовано разное поведение(или известные баги). Тут тоже не всё так гладко как хотелось бы, и применение bpl в проекте delphi-only более предпочтительно чем dll.
Применение dll в проекте на делфи оправдано только если этот модуль может быть использован в стороннем приложении.
Клиент Skype для Windows написан на Delphi. Так, между прочим
А для меня Делфи это как Ардуино, ничего крупного на ней не сделаешь, но всякую одноразовую мелочь делать можно очень быстро
У неё же астрономическая стоимость, если мне не изменяет память. Или вы про былые времена?
Единственное чего мне хватает в дельфи так это сервера приложений, и фреймворка на подобие asp.mvc, жаль что с орм тоже беда! многие бы полюбили дельфи за эти фичи!
так это сервера приложений
Кто ж мешает его реализовать самому, на том же Delphi.
вы либо не знаете, что такое application server, либо просто троллите. Для одиночки тут работы на несколько лет фулл-тайм
Во-первых, оговорок про одиночку нигде выше не было. Возьмите команду и сделайте.
Во-вторых, одиночка-кодер-формошлеп и одиночка-профи-гуру это разные разработчики. Один не сделает, другой сделает.
В-третьих мы сами небольшой командой (3-5 человек) пишем на Delphi сервер-mid-tier. Может это и не сервер приложений в вашем понимании (не Tomcat или что-то ему подобное), но все равно близко по смыслу. Это многопоточная сетевая служба, которая принимает запросы по TCP с множества клиентов, диспетчиризирует каждый запрос в ту или иную «логическую службу», логическая служба их обрабатывает (в отдельном потоке), в т.ч. общается с базой данных если это требуется, и отправляет ответ клиенту. Сервер может работать в режиме 24/7 произвольное время.
Во-вторых, одиночка-кодер-формошлеп и одиночка-профи-гуру это разные разработчики. Один не сделает, другой сделает.
В-третьих мы сами небольшой командой (3-5 человек) пишем на Delphi сервер-mid-tier. Может это и не сервер приложений в вашем понимании (не Tomcat или что-то ему подобное), но все равно близко по смыслу. Это многопоточная сетевая служба, которая принимает запросы по TCP с множества клиентов, диспетчиризирует каждый запрос в ту или иную «логическую службу», логическая служба их обрабатывает (в отдельном потоке), в т.ч. общается с базой данных если это требуется, и отправляет ответ клиенту. Сервер может работать в режиме 24/7 произвольное время.
Кто ж мешает его реализовать самому, на том же DelphiЭто подразумевает одного человека, а не команду.
Tomcat — это не application server, это просто servlet container, который может обрабатывать входящие http запросы, передавая их задеплоенному внутри приложению.
Application server — это целая платформа для хостинга приложений (одного или многих) внутри него, менеджмента самих этих приложений, менеджмента ресурсов, которые доступны приложениям, предоставление функций для разработчиков приложений: dependency injection, ORM, транзакции (не только SQL, а любые, в том числе распределенные), http эндпоинты, message queue, кластеризация, кэширование, пулы соединений, task scheduling, поддержка веб-сервисов, авторизация и еще куча всего, потому что всё не вспомнить. И всё это средствами самого application server без использования дополнительных фреймворков. Боюсь, что один человек не осилит даже требования проработать, не говоря уже о написании продукта
Можете тогда назвать пример сервера приложений, не связанного с JavaEE?
Всю платформу Net с её ADO.NET, ASP.NET, DI, ORM и т.п. и т.д. по-моему вполне можно считать сервером приложений… И вроде питоновский Zope тоже считается сервером приложений.
Нет, не могу, потому что во-первых, я не пользуюсь серверами приложений, а во-вторых, я — java программист и с другими экосистемами знаком только на уровне фреймворков.
Самое забавное что трое заминусовали коммент, А то что в ентерпрайзе юзаются ASP.NET, Java этот факт никто в расчет не берет.
Да конечно в дельфи нет ОРМ, веб сервера, хорошо поддерживаемого фреймворка для написания того же MVC.
Но все равно меня заминусовали так как топик дельфийский. Я просто хотел сказать что из-за того что в дельфи нет сервера приложений и веб сервера, мне приходиться изучать платформу .Net так как там есть и MVC и Nhibernate. Так сказать расти дальше для Ентерпрайза. Сахарок HTML +JS притягивает.
Да конечно в дельфи нет ОРМ, веб сервера, хорошо поддерживаемого фреймворка для написания того же MVC.
Но все равно меня заминусовали так как топик дельфийский. Я просто хотел сказать что из-за того что в дельфи нет сервера приложений и веб сервера, мне приходиться изучать платформу .Net так как там есть и MVC и Nhibernate. Так сказать расти дальше для Ентерпрайза. Сахарок HTML +JS притягивает.
Бл@ть, опять?!
Низкий порог вхождения (я про Delphi) привлекал школьников, но у них с платёжеспособностью проблемы.
Может хоть новые хозяева обратят внимание на IDE и доведут её до ума. Кросплатформенность, мобильные приложения — это всё хорошо, но пишутся то они в IDE все… а там работы там хватает.
IDE Дельфевая всегда фору давала другим IDE. Я не слежу за их деятельностью уже лет 5, но судя по тому, что Visual Studio и QtCreator которыми я пользуюсь до сих пор не умеют многого что умела дельфи 5 лет назад — ситуация пока не изменилась.
Например?
Ctrl+Shift+C в дельфи, Alt+Enter в Qt Creator, а в студии?
При том что в дельфи оно с начала времен существует.
Переход по Ctrl между интерфейсом и имплементацией. Почему надо хоткей нажимать? Причем в студии до сих пор работает через раз.
При том что в дельфи оно с начала времен существует.
Переход по Ctrl между интерфейсом и имплементацией. Почему надо хоткей нажимать? Причем в студии до сих пор работает через раз.
Вторая часть — чистой воды холивар
Я согласен что вариант хоткей/мышь — дело вкуса.
Но я не уверен в стабильности перехода в студии. ПРимерно в половине случае студия тупит при попытке перехода или вообще ничего не делает. В дельфе если интерфейс и имплементация идеентичны переход будет 100%. И даже если отличаются, все равно есть шанс что IDE поймет что искать и найдет.
Понятно, что многие фишки в дельфи сделаны изначально и хорошо, потому что они разрабатывались одновременно с языком.
Но я поэтому и не указываю в качестве примеров вещи, которые на языке завязаны. Уж поиск соответствия между имплементацией и интерфейсом не проблема сделать, особенно в ситуациях, когда не нарушается принцип интерфейс в хидере, имплементация в одноименном cpp.
Но я не уверен в стабильности перехода в студии. ПРимерно в половине случае студия тупит при попытке перехода или вообще ничего не делает. В дельфе если интерфейс и имплементация идеентичны переход будет 100%. И даже если отличаются, все равно есть шанс что IDE поймет что искать и найдет.
Понятно, что многие фишки в дельфи сделаны изначально и хорошо, потому что они разрабатывались одновременно с языком.
Но я поэтому и не указываю в качестве примеров вещи, которые на языке завязаны. Уж поиск соответствия между имплементацией и интерфейсом не проблема сделать, особенно в ситуациях, когда не нарушается принцип интерфейс в хидере, имплементация в одноименном cpp.
Понятно, что многие фишки в дельфи сделаны изначально и хорошо, потому что они разрабатывались одновременно с языком.
Ну тогда начнём с того, что практически весь .NET (поправьте меня, если ошибаюсь) заточен под си шарп, в котором нет привычного понятия интерфейса и имплементации, все функции инлайновые, поэтому переход по Ctrl — костыль и архаизм.
Я долгое время работал в Студии, потом обстоятельства вынудили перейти на сабж. И такое ощущение, что на 10 лет назад в прошлое отправился. Да, моя версия не самая свежая (XE2), но она вышла позже 2010-й студии… В ней нет ни нормальной генерации кода, ни вменяемого рефакторинга, ни инкрементальной компиляции. Те же самые интерфейсы и реализации приходится вбивать ручками, причём она норовит вставить бегин-енд по два раза — когда дополняет имя класса и когда дополняет собственно метод. Параметры при этом она не дополняет. Ощутимы задержки при открытии не самых сложных форм. Если пользоваться группой проектов, в них нормально не работают зависимости, иногда они тупо не проставляются. Хреново работает поддержка гуидов проектов — более новые версии той же XE ругаются на одинаковые гуиды.
К моим бедам добавляется то, что я работаю в виртуалке, проекты лежат в расшаренной папке, соответственно задержки при попытке прочитать таблицы для автоматической подстановки кода оказываются просто астрономическими. Соответственно, приходится CodeInsight отключать. В итоге у меня получается очень тормозной блокнот с некоторыми возможностями отладки и компиляции приложения по хоткею. Не скажу, что Студия идеальна, у неё тоже много проблем при работе в виртуалке, но при взгляде на Дельфи — таки она кажется совершенством.
Давайте подробнее.
Пожалуйста пример.
Пожалуйста пример.
Что, простите? :))
Вы хотите сказать, что любое изменени исходника на дельфи ведет к полному ребилду проекта? :))
Ctrl+Shift+C не работает? Это странно.
Кстати, а как вы генерируете имплементацию в студии?
Пока наверно остановлюсь с вопросами, когда с этими разберемся — продолжу задавать. :)
В ней нет ни нормальной генерации кода
Пожалуйста пример.
ни вменяемого рефакторинга
Пожалуйста пример.
ни инкрементальной компиляции
Что, простите? :))
Вы хотите сказать, что любое изменени исходника на дельфи ведет к полному ребилду проекта? :))
Те же самые интерфейсы и реализации приходится вбивать ручками
Ctrl+Shift+C не работает? Это странно.
Кстати, а как вы генерируете имплементацию в студии?
Пока наверно остановлюсь с вопросами, когда с этими разберемся — продолжу задавать. :)
Хмм.
Допустим, в Студии я могу написать что-то вроде «добавь воды в чайник», не объявив заранее чайник и воду, и она предложит мне сгенерировать метод «добавить» и переменные «чайник» и «вода». Причём если у меня есть объект класса «чайник», то мне достаточно написать «чайник.добавить(вода)» и разрешить студии его сгенерировать. Если тип переменной «вода» уже известен, то метод создаётся в соответствующем классе и с нужным типом параметров. Это самый простой пример, который приходит на ум. Точно так же можно объявить новый класс — просто напечатав подряд два неизвестных идентификатора в теле существующего класса. Студия будет считать первый новым классом, а второй — объектом этого класса.
В плане рефакторинга — очень много ограничений. Можно создать только процедуру, функцию нельзя, из части другой процедуры, в которую параметры передаются вообще не те, которые надо. Мне бывает нужно преобразовать структуру программы так, чтобы передавать литералы в метод, а Дельфи передаст сами объекты, в целом код в новый метод перенесётся без изменений, и литералы придётся заменять вручную. Насчёт Студии точно сказать уже не могу, но создавалось ощущение, что она «понимала», что я хочу сделать и зачем — литералы она заменяла самостоятельно, и ей не было разницы, хочу я функцию, или процедуру — если слева от выделения стоит "=", она создаёт функцию типа той переменной, которой будет присваиваться значение. Я понимаю, что наивно ожидать от машины, что она будет выполнять все твои пожелания, но в си шарпе правда было удобно писать код, не задумываясь, что он опирается на те возможности, которые ещё не реализованы.
Инкрементальная компиляция — рискну предположить, что вы неверно понимаете смысл данной функции. Суть в том, что любой метод можно переписать непосредственно во время исполнения, практически так же, как и в интерпретируемых языках. Любое изменение исходника на Дельфи ведёт к остановке программы и перекомпиляции проекта. Если приложение тяжёлое, из нескольких пакетов, то скорость разработки значительно падает.
Насчёт Ctrl-Shift-C кстати не знал, спасибо. В си шарпе, повторюсь, нет необходимости генерировать интерпретацию методов, они все инлайновые. Генерируется как раз-таки интерфейс, то есть в сторонней библиотеке внутренний код вы посмотреть не сможете, но вам будет доступна исчерпывающая информация о том, какие методы и свойства объявлены публично.
Допустим, в Студии я могу написать что-то вроде «добавь воды в чайник», не объявив заранее чайник и воду, и она предложит мне сгенерировать метод «добавить» и переменные «чайник» и «вода». Причём если у меня есть объект класса «чайник», то мне достаточно написать «чайник.добавить(вода)» и разрешить студии его сгенерировать. Если тип переменной «вода» уже известен, то метод создаётся в соответствующем классе и с нужным типом параметров. Это самый простой пример, который приходит на ум. Точно так же можно объявить новый класс — просто напечатав подряд два неизвестных идентификатора в теле существующего класса. Студия будет считать первый новым классом, а второй — объектом этого класса.
В плане рефакторинга — очень много ограничений. Можно создать только процедуру, функцию нельзя, из части другой процедуры, в которую параметры передаются вообще не те, которые надо. Мне бывает нужно преобразовать структуру программы так, чтобы передавать литералы в метод, а Дельфи передаст сами объекты, в целом код в новый метод перенесётся без изменений, и литералы придётся заменять вручную. Насчёт Студии точно сказать уже не могу, но создавалось ощущение, что она «понимала», что я хочу сделать и зачем — литералы она заменяла самостоятельно, и ей не было разницы, хочу я функцию, или процедуру — если слева от выделения стоит "=", она создаёт функцию типа той переменной, которой будет присваиваться значение. Я понимаю, что наивно ожидать от машины, что она будет выполнять все твои пожелания, но в си шарпе правда было удобно писать код, не задумываясь, что он опирается на те возможности, которые ещё не реализованы.
Инкрементальная компиляция — рискну предположить, что вы неверно понимаете смысл данной функции. Суть в том, что любой метод можно переписать непосредственно во время исполнения, практически так же, как и в интерпретируемых языках. Любое изменение исходника на Дельфи ведёт к остановке программы и перекомпиляции проекта. Если приложение тяжёлое, из нескольких пакетов, то скорость разработки значительно падает.
Насчёт Ctrl-Shift-C кстати не знал, спасибо. В си шарпе, повторюсь, нет необходимости генерировать интерпретацию методов, они все инлайновые. Генерируется как раз-таки интерфейс, то есть в сторонней библиотеке внутренний код вы посмотреть не сможете, но вам будет доступна исчерпывающая информация о том, какие методы и свойства объявлены публично.
Допустим, в Студии я могу написать что-то вроде «добавь воды в чайник», не объявив заранее чайник и воду, и она предложит мне сгенерировать метод «добавить» и переменные «чайник» и «вода».
Это как выглядит на практике?
Я ничего такого в студии не вижу:
Причём если у меня есть объект класса «чайник», то мне достаточно написать «чайник.добавить(вода)» и разрешить студии его сгенерировать.
И этого я не вижу тоже:
Инкрементальная компиляция — рискну предположить, что вы неверно понимаете смысл данной функции.
Полагаю что это вы не верно понимаете смысл этого термина:
An incremental compiler is one that can recompile only those portions of a program that have been modified. Ordinary compilers must process entire modules or programs.
en.wikipedia.org/wiki/Incremental_compiler
Там, кстати, дельфи в списке инкрементальный компиляторов.
Вы как-то упорно не замечаете, что я говорю про си шарп. С# который, сисярпом ещё в шутку именуемый. Не плюсы. Вы ещё скажите, что там формы до сих пор можно разрабатывать только в виде редактора диалогов. Поддержка плюсов в студии — костыль, Managed C++ — содомия и разврат.
А как бы перекомпиляция метода во время исполнения ни называлась, в Дельфи её нет…
А как бы перекомпиляция метода во время исполнения ни называлась, в Дельфи её нет…
Я, честно говоря, думал что вы C# приводите в качестве идеального примера, потому что я изначально говорил о сравнении с C++ IDE.
Так то, тот же Eclipse по возможностям при работе с Java уделывает и дельфи и С++ студию.
Но, я уже об этом говорил:
Все эти фишки шарпа они проще реализуемы в силу специфики языка.
Delphi же нативный язык, как и С++. При этом С++ IDE во многом хуже себя ведут чем дельфи и только недавно многие из своих фишек получили, которые были в дельфи чуть ли не с самого начала.
Так то, тот же Eclipse по возможностям при работе с Java уделывает и дельфи и С++ студию.
Но, я уже об этом говорил:
Но я поэтому и не указываю в качестве примеров вещи, которые на языке завязаны
Все эти фишки шарпа они проще реализуемы в силу специфики языка.
Delphi же нативный язык, как и С++. При этом С++ IDE во многом хуже себя ведут чем дельфи и только недавно многие из своих фишек получили, которые были в дельфи чуть ли не с самого начала.
Да, тоже подумал, что управляемые языки с нативными несколько некорректно сравнивать. Вот мы и достигли консенсуса :)
Правда к возможностям языка Дельфи у меня нет претензий, у него даже методы расширения классов (хелперы) реализованы изящнее, чем в шарпе. А вот пользовательскую оболочку можно было получше сделать. И функционала, и его качественной реализации катастрофически не хватает. Студия значительно проигрывает по функционалу, если говорить о поддержке нативных языков, но то, что там имеется, работает безупречно.
Ещё хотел заметить, что многие фичи в нативных языках появились благодаря влиянию управляемых, но это уже тема для отдельной беседы.
Правда к возможностям языка Дельфи у меня нет претензий, у него даже методы расширения классов (хелперы) реализованы изящнее, чем в шарпе. А вот пользовательскую оболочку можно было получше сделать. И функционала, и его качественной реализации катастрофически не хватает. Студия значительно проигрывает по функционалу, если говорить о поддержке нативных языков, но то, что там имеется, работает безупречно.
Ещё хотел заметить, что многие фичи в нативных языках появились благодаря влиянию управляемых, но это уже тема для отдельной беседы.
К вопросу об «инкрементальной компиляции», которая на самом деле «edit and continue» – она в студии есть и для нативного C++. Начиная с VS6, емнип.
И кроме её отсутствия еще раздражало то, что нельзя было текущую выполняемую строку сменить при отладке (например выполнить кусок кода еще раз после изменения значений в переменных)
И кроме её отсутствия еще раздражало то, что нельзя было текущую выполняемую строку сменить при отладке (например выполнить кусок кода еще раз после изменения значений в переменных)
В C# надо лампочку дождаться или Ctrl+. нажать, там и будут предложены выходы из ситуации.
написать что-то вроде «добавь воды в чайник», не объявив заранее чайник и воду, и она предложит мне сгенерировать метод «добавить» и переменные «чайник» и «вода».
Это ж вроде только в Решарпере, а не самой студии?
Для Дельфи впрочем ничего сравнимого с Решарпером вообще нет.
Мне вот тоже интересно — что она такого умеет?
Программировал на Delphi плотно до 2005 года, и при этом совершенно не страдал ни от языка, ни от IDE.
После этого ушёл в web. PhpShtorm, а теперь вот и Idea.
С выходом XE8 решил попробовать — как там оно, с разработкой кроссплатформенных приложений?
И вот сейчас, после Idea, IDE Delphi представляется мне просто адом. Достаточно одного лишь автокомплита, не срабатывающего до тех пор, пока ты не исправишь все ошибки выше по тексту. Это просто сплошное страдание.
Я бы с удовольствием использовал Delphi, получи она нормальную среду разработки.
После этого ушёл в web. PhpShtorm, а теперь вот и Idea.
С выходом XE8 решил попробовать — как там оно, с разработкой кроссплатформенных приложений?
И вот сейчас, после Idea, IDE Delphi представляется мне просто адом. Достаточно одного лишь автокомплита, не срабатывающего до тех пор, пока ты не исправишь все ошибки выше по тексту. Это просто сплошное страдание.
Я бы с удовольствием использовал Delphi, получи она нормальную среду разработки.
Согласен. ИДЕ порой бесит, в ней недостаёт согласованности с компилятором (порой ИДЕ красит красным «ошибки» и отказывается открывать автодополнение, а ошибок нет, просто в компиляторе появились новые фичи, о которых почему-то ИДЕ ничего не знает). Нехватает возможностей открывать два файла рядышком, Как в студии, а не на разных закладках. Совершенно непрозрачная поддержка неймспейсов — камень как в среду, так и в компилятор. Зачем нужны неймспейсы, если вложенности не считаются?
Нехватает возможностей открывать два файла рядышком, Как в студии, а не на разных закладках.
Примерно вот так?
Заголовок спойлера
Очень часто в недостатки дельфи записывают то, что просто не знают как сделать.
Нет уж, скорее так:
Заголовок спойлера
Эээ. Отличается тем что окно в доке?
UPD: кстати да, у меня в 2009 дельфи второй редактор в док не пихается.
Интересно, в новой дельфе также или нет.
UPD: кстати да, у меня в 2009 дельфи второй редактор в док не пихается.
Интересно, в новой дельфе также или нет.
Ну, в первую очередь в split режиме окна друг друга не перекрывают.
Вы в левом окне курсором пойдете по длинной строке вправо за границу видимой зоны (строка 347), а вас курсор из виду скроется, а в сплит-режиме просто скрол горизонтальный сработает.
Вы в левом окне курсором пойдете по длинной строке вправо за границу видимой зоны (строка 347), а вас курсор из виду скроется, а в сплит-режиме просто скрол горизонтальный сработает.
Тем, что оно не уходит на задний план.
Полагаю вы и не пробовали никогда открыть второе окно с кодом в Delphi и, вероятно, думали, что такого функционала вообще нет.
Это окно НЕ уходит на второй план. Оно даже если теряет фокус остается над IDE.
Это окно НЕ уходит на второй план. Оно даже если теряет фокус остается над IDE.
Полагаю вы никогда не пробовали подобный функционал в вижуалстудии (см. скриншот выше), иначе бы не пытались оправдать это жалкое подобие.
Окей, оратор выше выразился внятнее, чем я. Окно физически не уходит назад, да. Но ведёт себя именно как ушедшее назад.
Скажите честно, при таком раскладе очень вам удобно пользоваться менеджером проектов, например?
А то, что он не позволяет открывать один и тот же модуль дважды, если это модуль формы, это нормально? Мне вот надо смотреть начало модуля и править конец одновременно.
Нет, это полумеры всё.
Окей, оратор выше выразился внятнее, чем я. Окно физически не уходит назад, да. Но ведёт себя именно как ушедшее назад.
Скажите честно, при таком раскладе очень вам удобно пользоваться менеджером проектов, например?
А то, что он не позволяет открывать один и тот же модуль дважды, если это модуль формы, это нормально? Мне вот надо смотреть начало модуля и править конец одновременно.
Нет, это полумеры всё.
Но ведёт себя именно как ушедшее назад.
Не вижу ничего, что делало бы его поведение похожим на «ушедшее назад».
Скажите честно, при таком раскладе очень вам удобно пользоваться менеджером проектов, например?
А я так и не использую. У меня два монитора.
А то, что он не позволяет открывать один и тот же модуль дважды, если это модуль формы, это нормально? Мне вот надо смотреть начало модуля и править конец одновременно.
Это ограничение визуального редактирования.
Плата за возможность быстро и удобно ваять GUI.
Говорить, что в студии в этом случае что-то лучше — странно, потому что в ней такого инструмента нет вообще. Если с дельфи работать также как со студией(не использовать визуальный дизайн), то и функционал будет такой же.
Нет, это полумеры всё.
Ну смешно же, вы привязались к тому, что окно не дочится и на этом построили целую претензию к функционалу.
ПРи том что проблема плавающего окна имеет как минимум два простых решения:
1) Выключаем MDI режим и расставляем все окна так как нам удобно, сохраняем в отдельный layout. надо подредактировать два файла — переходим в этот layout. закончили — возвращаемся в MDI.
2) Второй монитор.
Я формы в делфи «ваяю» крайне редко визуально. Так что для меня важно именно удобство работы с кодом. А оно явно проигрывает студии.
Не смешно. Это неудобно. В этом случае все окна идут вперемешку, Начинают налезать другие программы, я этого еще во времена делфи5-7 наелся и был несказанно рад монолитному окошку в 2005й делфи.
Право, не у всех есть возможность поставить себе два монитора. И причин тому может быть масса, начиная от банальной нехватки места, куда его можно было бы поставить. Да и я не очень себе представляю это решение, когда кодить нужно с ноутбука в пути, или командировке. Это костыли всё.
Выключаем MDI режим и расставляем все окна так как нам удобно
Не смешно. Это неудобно. В этом случае все окна идут вперемешку, Начинают налезать другие программы, я этого еще во времена делфи5-7 наелся и был несказанно рад монолитному окошку в 2005й делфи.
2) Второй монитор.
Право, не у всех есть возможность поставить себе два монитора. И причин тому может быть масса, начиная от банальной нехватки места, куда его можно было бы поставить. Да и я не очень себе представляю это решение, когда кодить нужно с ноутбука в пути, или командировке. Это костыли всё.
Думаю, возможность сравнительно быстро набросать форму в графическом режиме вкупе с поддержкой нативного кода спасает Дельфи от полного забвения. В VS при работе с С++ приходится довольствоваться древнейшим редактором диалогов, а главное окно так вообще до запуска приложения не увидеть. В Дельфи кстати тоже создаётся главное окно, но оно невидимо. Вместо него запускается MainForm, которая по сути является допиленным диалоговым окном (если говорить строже, идея визуального редактора в ней доведена до ума) и построена на VCL.
И таки да, компилятор языка Дельфи крайне быстр, что тоже играет свою роль. Пока «насильники» соберутся, «греки» уже заберут всех девок себе ;)
И таки да, компилятор языка Дельфи крайне быстр, что тоже играет свою роль. Пока «насильники» соберутся, «греки» уже заберут всех девок себе ;)
Стесняюсь спросить, а покупка второго монитора только ради того, чтобы скомпенсировать отсутствие дока, как-то оправдана финансово? Вы, конечно, скажете, что второй монитор — всегда хорошо, но с ним становится хорошо независимо от того, в чём вы будете работать. Второй монитор также не решит проблему тормозов и глючного отладчика.
У рекорда есть такое определение у меня:
Какого черта IDE мне везде пихает strict private вместо проперти в автодополнении, а потом при компиляции ругается сама же на это?
Почему константы, определнные в хелпере подставляются автокомплитом от имени хелпера, а не базового класса. ИДЕ ругается, но продолжает сама подставлять.
ИДЕ постоянно перемешивает модули в DPR файле, дублирует их, игнорируя дефайны. У Среды очень много проблем, но их не фиксят уже лет 10. Как они появились в 2005 версии, так и идут. Зато кроссплатформенность, да.
strict private
class var FZero: TVec2f;
public
class property Zero: TVec2f read FZero;
Какого черта IDE мне везде пихает strict private вместо проперти в автодополнении, а потом при компиляции ругается сама же на это?
Почему константы, определнные в хелпере подставляются автокомплитом от имени хелпера, а не базового класса. ИДЕ ругается, но продолжает сама подставлять.
ИДЕ постоянно перемешивает модули в DPR файле, дублирует их, игнорируя дефайны. У Среды очень много проблем, но их не фиксят уже лет 10. Как они появились в 2005 версии, так и идут. Зато кроссплатформенность, да.
У Среды очень много проблем, но их не фиксят уже лет 10. Как они появились в 2005 версии, так и идут. Зато кроссплатформенность, да.
Как мне кажется, люди, разработавшие платформу, уволились, а индусы, которые пришли на их место, не разобравшись в написанном до них, стали писать свой код, реализовывая поддержку всего что только можно. Это в частности объясняет перманентность многих проблем. И это довольно странно, учитывая насколько грамотно написана сама VCL. Не разобраться в таком коде способен только изрядный лентяй.
Хотя в их защиту можно сказать, что Win32 API тоже не блещет изяществом, и возможно под капотом код дельфей далеко не так гламурен, как высокоуровневая реализация в VCL…
Какого черта IDE мне везде пихает strict private вместо проперти в автодополнении, а потом при компиляции ругается сама же на это?
Почему константы, определнные в хелпере подставляются автокомплитом от имени хелпера, а не базового класса. ИДЕ ругается, но продолжает сама подставлять.
Можно писать программу грамотно, максимально используя все имеющиеся возможности, как заранее существующие, так и реализованные самостоятельно. В результате имеем Визуал Студио, в которой автокомплит в окне просмотра переменных работает аналогично основному редактору. Но и не студией единой. (У неискушённого читателя может сложиться мнение, что я пою дифирамбы Корпорации Зла, но Студия и впрямь хороша, как и Офис, впрочем.) Eclipse тоже хорош, но мне удалось лишь слегка пощупать джаву, а в С++ я пока так ничего и не пытался сделать.
А можно писать так, как написана Дельфи. В результате в окне Watch бывает нельзя просмотреть переменные или вызов какого-либо метода генерирует весьма не безобидное исключение, после которого программа по идее вообще должна вылететь. При этом программа работает нормально, несмотря на то, что в коде вызывается тот же самый метод. Гораздо хуже то, что толку от такой отладки практически нет, и приходится выводить значения переменных месседжами или в лог. А другие операции с отладчиком, гораздо более невинные, достаточно часто вызывают переполнение стека и прочие неприятности. Иногда отладчик останавливается, как упрямый осёл, и никакие меры не могут заставить продолжать выполнение кода дальше, и приходится запускать отладку заново. Сказать, что это меня бесит — ничего не сказать.
Именно так.
А вы в виртуалке попробуйте, а потом на реальной машине ;)
У меня сложилось стойкое ощущение, что если в программе есть хоть малейший косяк, Дельфи обижается и начинает пакостить. Сначала отваливается Watch, потом Inspect, а в особо тяжких случаях она начинает останавливаться по брейкпойнту исключительно в CPU View. Не говорим уже о том, что она никогда не покажет, какое место ТВОЕГО кода вызвало ошибку, может тупо вылететь в процессе исполнения от External Error, или «уехать» куда-то в неизведанные области памяти.
Говорят, что те, кто «не в восторге» от Дельфи, просто его «ниасилили». В ответ можно сказать, что те, кто считает его нормальной средой, «ниасилили» остальные среды и не привыкли к хорошему.
У меня сложилось стойкое ощущение, что если в программе есть хоть малейший косяк, Дельфи обижается и начинает пакостить. Сначала отваливается Watch, потом Inspect, а в особо тяжких случаях она начинает останавливаться по брейкпойнту исключительно в CPU View. Не говорим уже о том, что она никогда не покажет, какое место ТВОЕГО кода вызвало ошибку, может тупо вылететь в процессе исполнения от External Error, или «уехать» куда-то в неизведанные области памяти.
Говорят, что те, кто «не в восторге» от Дельфи, просто его «ниасилили». В ответ можно сказать, что те, кто считает его нормальной средой, «ниасилили» остальные среды и не привыкли к хорошему.
Может наконец-то и стартер сделают бесплатным. По крайней мере я на это надеюсь. Это бы привлекло много молодежи в ряди делфистов.
Sign up to leave a comment.
Компания Embarcadero Technologies продана компании Idera