Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 380
Не сочтите меня враждебно настроенным, но я думал, что на Делфи уже никто не пишет?!
Почему, пишут еще. В гос.организациях всяких почти сплошь Delphi.
Прав )
А еще старые проекты есть, которые руководство нехочет переделывать на других языках.
А еще старые проекты есть, которые руководство нехочет переделывать на других языках.
QIP какой-нибудь, к примеру…
Вообще Delphi сейчас совсем выдохся и чем-то начинает напоминать Cobol по своей роли
Вообще Delphi сейчас совсем выдохся и чем-то начинает напоминать Cobol по своей роли
Ну… по крайней мере на нем учиться легко.
Не уверен. Учится легко на паскале. А уж если хочется гуй делать, то лучше тогда C# учить на первое время
я сразу учился писать приложения еще в школе на си, и почему то проблем не возникло
можете объяснить в чем же особенная легкость изучения Delphi?
можете объяснить в чем же особенная легкость изучения Delphi?
В строгости, он имеет более строгие правила в синтаксисе, например самое первое — это необходимость описывать все используемые переменные перед телом функции.
А вообще проще посмотреть вам, чем нам это рассказывать.
А вообще проще посмотреть вам, чем нам это рассказывать.
И чего? Для меня это скорее минус. Невозможно рулить областями видимости. Я вот не хочу, чтобы временная переменная была видна вне цикла.
Не путайте Си и C++. (:
Чо? Ваще то как раз и имелось в виду изучение Си вместо Паскаля.
> в чем же особенная легкость изучения Delphi?
А я не вам отвечал, но…
> в чем же особенная легкость изучения Delphi?
> необходимость описывать все используемые переменные перед телом функции
В стандарте Си, не самом новом, правда, переменные тоже в начале функции объявлять надо.
> в чем же особенная легкость изучения Delphi?
> необходимость описывать все используемые переменные перед телом функции
В стандарте Си, не самом новом, правда, переменные тоже в начале функции объявлять надо.
Это я к тому, что Си, на самом деле, очень строгий язык. Это вот C++ весь такой undefined behavour.
Там нельзя сделать многих типично сишных ошибок, вроде присваивания вместо сравнения. Там сборка крупных проектов выполняется быстро, а коротких — мгновенно. Там нет заголовочных файлов и макросов.
передаешь gcc ключи -Wall -Werror и забываешь в принципе о пропуске таких ошибок
хм, выдавать в качестве минуса языка его мощь? чем лично Вам помешали макросы? и тоже самое касается хидеров — никто не заставляет вас в проекте их использовать — пишите все в cpp файлах, какие проблемы?
только от этого код станет менее читабельным, что в общем то и наблюдается в таких языках как Java/Delphi/etc, в которых все тело класса пишется в одном файле и поэтому без ide в крупных классах что-то найти — малореально. до сих пор с ужасом вспоминаю код r&q (или &rq, точно не помню)
хм, выдавать в качестве минуса языка его мощь? чем лично Вам помешали макросы? и тоже самое касается хидеров — никто не заставляет вас в проекте их использовать — пишите все в cpp файлах, какие проблемы?
только от этого код станет менее читабельным, что в общем то и наблюдается в таких языках как Java/Delphi/etc, в которых все тело класса пишется в одном файле и поэтому без ide в крупных классах что-то найти — малореально. до сих пор с ужасом вспоминаю код r&q (или &rq, точно не помню)
>QIP какой-нибудь, к примеру…
От зависти в зобу дыханье сперло?
На Дельфи еще какой-то Skype написан — его разработчики тоже наверно жаждут причаститься к благодати Qt, но что-то им мешает.
От зависти в зобу дыханье сперло?
На Дельфи еще какой-то Skype написан — его разработчики тоже наверно жаждут причаститься к благодати Qt, но что-то им мешает.
ВНЕЗАПНО! Но Linux версия Skype сделана на Qt4.
Пройдет пара лет и qip, в привычном нам смысле, на покой отправится. РБК всё делает для этого))
Пройдет пара лет и qip, в привычном нам смысле, на покой отправится. РБК всё делает для этого))
странно, но у меня информация, что Skype как раз таки писан на Qt
$ aptitude show skype
Пакет: skype
Раздел: non-free/net
Сопровождающий: Skype Technologies <info@skype.net>
Зависимости: libasound2 (> 1.0.17), libc6 (>= 2.7-1), libgcc1 (>= 1:4.3), libqt4-dbus (>= 4.4.3), libqt4-network (>= 4.4.3), libqtcore4 (>= 4.4.3), libqtgui4 (>= 4.4.3), libstdc++6
(>= 4.3), libx11-6, libxext6, libxss1, libxv1
Для Линукса — неудивительно :)
однако иди учить матчасть, а то ты все гадаешь, гадаешь, пытаешься что-то придумать, а получается криво)
и да, до сих пор ни одного вменяемого аргумента не услышал, судя по всему ты все таки просто не осилил плюсы
и да, до сих пор ни одного вменяемого аргумента не услышал, судя по всему ты все таки просто не осилил плюсы
А подумать, почему сделав Linux-версию на Qt, Windows-версию сделали на Delphi, не судьба?
Или обсирание чужого инструмента при недостаточном владении собственным для тебя самоцель?
Или обсирание чужого инструмента при недостаточном владении собственным для тебя самоцель?
а можно пруф-линк, что я обсирал Дельфи? или опять выхлоп в связи с отсутствием аргументов?
> только от этого код станет менее читабельным, что в общем то и наблюдается в таких языках как Java/Delphi/etc, в которых все тело класса пишется в одном файле и поэтому без ide в крупных классах что-то найти — малореально.
В дельфи в любом модуле есть секция interface. Дальше продолжать или сам поймешь?
В дельфи в любом модуле есть секция interface. Дальше продолжать или сам поймешь?
Даже Sun признает этот факт, как разработчик и создатель языка Java + здесь идет критика не столько Delphi, сколько самого подхода «все в одном файле», пример с Java как бы намекает
знаю, но я все таки говорил про чистое чтение кода, без ide/генераторов документации.
и да, у всех остальных языков сейчас есть Doxygen, который поддерживает в том числе комментирование в стиле JavaDoc'а
и да, у всех остальных языков сейчас есть Doxygen, который поддерживает в том числе комментирование в стиле JavaDoc'а
Мне приходилось по роду задач изучать исходники множества проектов, в том числе злосчастного &RQ написанного на Delphi, а так как возможности поставить IDE для этого языка нет (в связи с используемой операционной системой) то приходилось пользоваться обычными текстовыми редакторами. И именно логика расположения реализации классов «все в одном файле» мешала больше всего при чтении исходников
Очевидно секции interface просмотру не подвергались из принципа — а то еще не дай бог окажется, что дельфи-код читается лучше.
Кстати, есть прекрасный кроссплатформенный редактор SciTE — он умеет делать фолдинг, подсветку синтаксиса и собирать список подпрограмм модуля. Для дельфи в том числе. Так что сначала стоит изучать матчасть, а уж потом жаловаться на трудности забивания гвоздей микроскопом.
Ну вот, наплодили каких-то лишних сущностей, которые прекрасно отрезаются бритвой Оккама, а теперь без специальных костылей уже и ориентироваться в них не можете
А для других языков генераторы документации из кода религия использовать запрещает? ;)
Читать же в любом случае надо прежде всего сам код — а с этим у явы имеются косяки.
Читать же в любом случае надо прежде всего сам код — а с этим у явы имеются косяки.
Откройте для себя комбинацию клавиш Ctrl+Shit+C, которую знает любой дельфист с хоть каким-то опытом.
> В Delphi стало угнетать необходимость дважды описывать одно и тоже.
Откройте для себя комбинацию клавиш Ctrl+Shit+C
Откройте для себя комбинацию клавиш Ctrl+Shit+C
Намекает на то, что дельфи ты не знаешь совсем.
И с явой сомнительно — подход там в точности обратный, по одному публичному классу на файл.
Между тем проблема читаемости связана совсем с другим, а именно с отделением интерфейса от реализации на уровне кода.
В си и плюсах это доступно благодаря возможности описания перед определением. Но никаких ограничений нет и описания спокойно можно разбросать по всему коду. Помогает совсем другое ограничение — необходимость описания всех внешних элементов перед их использованием. А поскольку описание экспортируемых и импортируемых элементов синтаксически одинаковое — его выделяют в заголовочный файл, который используется в обоих случаях.
В яве и шарпе заголовочные файлы справедливо убрали как анахронизм, но с водой выплеснули и ребенка — в результате личный, публичный и защищенный интерфейсы модуля (класса) при чтении кода увидеть сложно и приходится для этого пользоваться услугами инструментальных средств (автодоки, фолдинг).
В дельфи используется другой подход, сочетающий преимущества обоих вышеупомянутых, но избавленный от их недостатков — все описания экспортируемых элементов принудительно размещаются в специальной секции, отдельной от реализации. В результате и оглавление в коде есть и файлов лишних нет и компиляция со сборкой много быстрее сишных.
И с явой сомнительно — подход там в точности обратный, по одному публичному классу на файл.
Между тем проблема читаемости связана совсем с другим, а именно с отделением интерфейса от реализации на уровне кода.
В си и плюсах это доступно благодаря возможности описания перед определением. Но никаких ограничений нет и описания спокойно можно разбросать по всему коду. Помогает совсем другое ограничение — необходимость описания всех внешних элементов перед их использованием. А поскольку описание экспортируемых и импортируемых элементов синтаксически одинаковое — его выделяют в заголовочный файл, который используется в обоих случаях.
В яве и шарпе заголовочные файлы справедливо убрали как анахронизм, но с водой выплеснули и ребенка — в результате личный, публичный и защищенный интерфейсы модуля (класса) при чтении кода увидеть сложно и приходится для этого пользоваться услугами инструментальных средств (автодоки, фолдинг).
В дельфи используется другой подход, сочетающий преимущества обоих вышеупомянутых, но избавленный от их недостатков — все описания экспортируемых элементов принудительно размещаются в специальной секции, отдельной от реализации. В результате и оглавление в коде есть и файлов лишних нет и компиляция со сборкой много быстрее сишных.
Интересное «сравнение». Второе — это не Java, а вывод генератора документации. Такой вывод и для дельфи получить несложно.
Прямой — не надо прыгать из кода в документацию и обратно.
ИМХО второй вариант еще и хуже. И не только тем, что компилятору его не скормить.
Я всегда предпочитаю смотреть код, если он доступен. А из документации брать те вещи, которые из кода неочевидны — принципы дизайна конкретной системы и примеры использования.
ИМХО второй вариант еще и хуже. И не только тем, что компилятору его не скормить.
Я всегда предпочитаю смотреть код, если он доступен. А из документации брать те вещи, которые из кода неочевидны — принципы дизайна конкретной системы и примеры использования.
Вот за что минусы в карму, делфи-ненавистники?
Я по своему опыту говорю. Сейчас работаю в организации, в которой 90% это Делфи программисты.
И я сейчас перевожу потихоньку всю прошлую разработку на .Net/Silverlight/WPF/ASPX.
Я по своему опыту говорю. Сейчас работаю в организации, в которой 90% это Делфи программисты.
И я сейчас перевожу потихоньку всю прошлую разработку на .Net/Silverlight/WPF/ASPX.
Гнать этих некрофилов пора! Гнать! Еще и 90% их. Ужас!
У нас два профессора программу для обработки данных как написали в девяносто лохматом году на паскале, так она до сих пор работает, постепенно обрастая новыми возможностями.
Т.е. если в вашей госорганизации на дельфи, то и везде так?
А вот в нашей госорганизации пишут на C#, используя asp.net mvc и прочие приблуды =)
Зато в МГУ видел что до сих пор пишут на delphi 7, да ещё как пишут — слепая обезъяна со сломанными пальцами лучше напишет, вот тут действительно клиника, обидно за универ.
А вот в нашей госорганизации пишут на C#, используя asp.net mvc и прочие приблуды =)
Зато в МГУ видел что до сих пор пишут на delphi 7, да ещё как пишут — слепая обезъяна со сломанными пальцами лучше напишет, вот тут действительно клиника, обидно за универ.
А я у себя в организации, где практику от универа прохожу, сразу сказал, что Дельфи юзать не буду, а буду писать на Qt и пускай потом после меня следующие поколения тоже теперь Qt юзают
а кто Вы такой навязывать организации да еще и будущим поколениям технологию? :)
На чем мне удобнее, на том и пишу… Раньше там народ приходил и писал кто на чем горазд, а потом руководству это надоело, что каждый следующий студент, проходящий практику, начинает заного велосипед изобретает, и сказало, что «давайте мы всё сделаем на привычных С++». Поэтому к взаимопониманию мы быстро пришли. А будущие поколения смогут на javascript'е дорабатывать приложение, если плюсы им не по зубам.
вспомнил одну из своих практик. Поставили нам задачу — сделать макрос, переводящий определнным образом сформированную таблицу excel в файл нужного формата (конфиг для каких-то встроенных устройств). Сделали.
Выяснилось, что до нас это же самое «делали» еще несколько поколений практикантов. Ага, морщили носы от VBA (видимо) и писали всякие извраты с переводом xls в csv с последующей обработкой perl'ом.
Story not related, просто навеяло.
Выяснилось, что до нас это же самое «делали» еще несколько поколений практикантов. Ага, морщили носы от VBA (видимо) и писали всякие извраты с переводом xls в csv с последующей обработкой perl'ом.
Story not related, просто навеяло.
Я не сказал везде. Я сказал, что практически сплошь и рядом.
Я общаюсь с друзьями-программистами и основываюсь не только на своем опыте, но и на их.
Мне тоже было обидно за свой ОренбургскийГУ, когда в нем преподают Delphi и Borland C++. А о C# там и думать не хотят. Каменный век.
Я общаюсь с друзьями-программистами и основываюсь не только на своем опыте, но и на их.
Мне тоже было обидно за свой ОренбургскийГУ, когда в нем преподают Delphi и Borland C++. А о C# там и думать не хотят. Каменный век.
Меня очень порадовала налоговая, где в 2009 году я сумел найти базу данных в FoxPro 2.0.
С другой стороны — кто C# преподавать-то будет за 20к-30к не считая взяток? маловато будет.
Да и вообще, вы ещё просто не видели как на макросах VBA в excel клиент-серверную архитектуру сделали умельцы и впаривают её всем теперь под протекцией государства — вот это жесть, уж лучше delphi.
Delphi не так уж и плохо для первого или второго в жизни языка программирования, писать может и не будете на нём, но кругозор, другие подходы узнаете. А то студент выучит C# будет считать крутым себя, а на деле нихрена не знает, ничего не умеет, дальше носа не видит, куда он приткнётся потом?
С другой стороны — кто C# преподавать-то будет за 20к-30к не считая взяток? маловато будет.
Да и вообще, вы ещё просто не видели как на макросах VBA в excel клиент-серверную архитектуру сделали умельцы и впаривают её всем теперь под протекцией государства — вот это жесть, уж лучше delphi.
Delphi не так уж и плохо для первого или второго в жизни языка программирования, писать может и не будете на нём, но кругозор, другие подходы узнаете. А то студент выучит C# будет считать крутым себя, а на деле нихрена не знает, ничего не умеет, дальше носа не видит, куда он приткнётся потом?
Как получается?
Я просто мечтаю перейти на .Net, потому что сейчас проще найти .Net программиста, чем Delphi программиста.
Я просто мечтаю перейти на .Net, потому что сейчас проще найти .Net программиста, чем Delphi программиста.
У нас вот какая ситуация: в отделе 15 человек. И уже написано, внедрено и сопровождается почти сотня ПК и различных модулей к ним. Уволить никого нельзя, да и не хочется. А расширять отдел начальство не даст.
Начальству была показана перспектива ухода от Delphi и переход в .Net и Web.
Да и пользователи наших программ будут рады — не надо постоянно выкачивать DLL,EXE и т.д. для новых версий.
И сами программисты понимают что надо развиваться и главное хотят этого.
Поэтому все новые проекты было предложено писать под web/silverlight/wpf. А уже морально устаревшие потихоньку переписать когда будет время.
Переход сопровождается чтением книг, просмотров techday видео-семинаров, видео-кастов и т.д.
Начальству была показана перспектива ухода от Delphi и переход в .Net и Web.
Да и пользователи наших программ будут рады — не надо постоянно выкачивать DLL,EXE и т.д. для новых версий.
И сами программисты понимают что надо развиваться и главное хотят этого.
Поэтому все новые проекты было предложено писать под web/silverlight/wpf. А уже морально устаревшие потихоньку переписать когда будет время.
Переход сопровождается чтением книг, просмотров techday видео-семинаров, видео-кастов и т.д.
Чтобы писать на дотнете самому — можно использовать призму.
Для связи дотнетных проектов с дельфийскими — RemObjects SDK (единый код для любого канала и протокола связи — от сообщений винды до TCPIP и e-mail, от SOAP до сжатого на лету бинарника).
Для связи дотнетных проектов с дельфийскими — RemObjects SDK (единый код для любого канала и протокола связи — от сообщений винды до TCPIP и e-mail, от SOAP до сжатого на лету бинарника).
Silverlight в итоге умер уже давно как, а Delphi живет и развивается )))
Хм, я же просто спросил и не являюсь ненавистником Делфи, просто давно ничего об этом не слышал
Вот тут есть некий рейтинг по… www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Пишут. Например, когда что-то быстренько нужно сделать, возможно даже и в черновом варианте…
А обычно оно в таком виде навсегда и остается((((
Лично у вас — верю
Я на Делфи уже лет 10 ничего не писал и больше писать никогда не буду уже))) Это не кроссплатформенно, да и нету многих привычных уже плюшек
Доживание чернового варианта до продакшена — особенность программиста, а не языка или платформы.
Так что если у вас на Дельфи все оставалось в сыром виде — то «кроссплатформенность и привычные уже плюшки» не помогут.
Кстати, если уж 10 ничего не писали — то все вашим тезисам о минусах Дельфи грош цена.
Так что если у вас на Дельфи все оставалось в сыром виде — то «кроссплатформенность и привычные уже плюшки» не помогут.
Кстати, если уж 10 ничего не писали — то все вашим тезисам о минусах Дельфи грош цена.
Заметьте, я ничего про минусы Дельфи не писал, я лишь сказал, что обычно все и остается на уровне чернового варианта и я даже не говорил, что это проблема языка.
А еще проект Lazarus — в принципе совместим с дельфи, и кроме того кроссплатформеный и полностью открытый!
Компонентов ему еще немного и действительно будет неплохая среда разработки.
Компонентов ему еще немного и действительно будет неплохая среда разработки.
Если Вас так интересует кроссплатформенность — то она будет в ближайшей версии
Delphi жив
Delphi жив
И чего? Мне кроссплатформенность нужна здесь и сейчас. Пока там Дельфийцы прикручивают непонятные костыли для поддержки других платформ, причем уже в который раз, я уже просто занимаюсь своим делом.
Да и не только в кроссплатформенности дело, когда в Дельфи появился полноценный юникод? Когда там наконец человеческая интернационализация появится, а не «руки», «левые либы» и win only ресурсные файлы? А тем временем шёл 2010ый год, когда в нормальных средах достаточно просто строки, нуждающиеся в локализации отдавать как аргумент функции tr(""); или i18n("");
А где хоть что-то похожее на state machine framework или WWF? Где хоть что-то аналогичное WPF?
Да и не только в кроссплатформенности дело, когда в Дельфи появился полноценный юникод? Когда там наконец человеческая интернационализация появится, а не «руки», «левые либы» и win only ресурсные файлы? А тем временем шёл 2010ый год, когда в нормальных средах достаточно просто строки, нуждающиеся в локализации отдавать как аргумент функции tr(""); или i18n("");
А где хоть что-то похожее на state machine framework или WWF? Где хоть что-то аналогичное WPF?
Java вам в руки.
С её жутким монстроподобным гуем? Ну уж нет… я лучше дальше Qt буду юзать
Плюсы как язык разработки за кроссплатформенность и гуй берут втридорога.
Это наверное у тех, у кого руки не из того места растут.
ЭЭэ… есть примеры кроссплатформенности с хорошим гуём?
QtCreator посмотрите на досуге.
Ну или вот мы сейчас делаем (еще в деталях не отточено)
itmages.ru/image/view/22286/90dc5aaa
itmages.ru/image/view/21479/395377
Но уже сейчас я могу смело сказать, что ничего подобного в QIPе никогда не будет, хотя бы в плане анимации.
А вот windows скрины старой версии:
sauron.me/images/qutim/winseven.png
sauron.me/images/qutim/yandexnarod.png
Ну и советую полазить по
qt-apps.org/
Гуй на каждой платформе поддерживает нативные стили плюс есть еще собственный движок стилей, скорость работы тоже не отличима от нативных приложений.
Ну или вот мы сейчас делаем (еще в деталях не отточено)
itmages.ru/image/view/22286/90dc5aaa
itmages.ru/image/view/21479/395377
Но уже сейчас я могу смело сказать, что ничего подобного в QIPе никогда не будет, хотя бы в плане анимации.
А вот windows скрины старой версии:
sauron.me/images/qutim/winseven.png
sauron.me/images/qutim/yandexnarod.png
Ну и советую полазить по
qt-apps.org/
Гуй на каждой платформе поддерживает нативные стили плюс есть еще собственный движок стилей, скорость работы тоже не отличима от нативных приложений.
Хорошие разработчики работают прежде всего головой.
И предпочитают не преодолевать корявость инструмента (плюсы), а тратить свое время и силы на решение поставленных задач.
И предпочитают не преодолевать корявость инструмента (плюсы), а тратить свое время и силы на решение поставленных задач.
Ну хорошо, где в таком инструменте как Qt корявость и почему там она больше, чем в VCL?
Если вы из плюсов видели только MFC, то мне вас жаль, вас обманули, это не плюсы, а ужас! Плюсы достаточно практичный язык, конечно далеко не идеальный и со своими особенностями, но тем не менее он обладает более богатыми возможностями, чем Delphi и имеет куда больше инструментов.
Если вы из плюсов видели только MFC, то мне вас жаль, вас обманули, это не плюсы, а ужас! Плюсы достаточно практичный язык, конечно далеко не идеальный и со своими особенностями, но тем не менее он обладает более богатыми возможностями, чем Delphi и имеет куда больше инструментов.
Qt — по отзывам очень хорошая библиотека.
VCL, кстати, как библиотека так себе — но для Дельфи есть JEDI (даром) и DevExpress(за деньги).
Корявым же инструментом являются сами плюсы.
Кстати, по части языковых возможностей последние плюсы превосходят последнюю Дельфи только по части метапрограммирования, но те, кому нужно именно оно на плюсах пишут разве что по крайней нужде.
Практичность плюсов — это кодогенераторы лучших компиляторов, богатый набор библиотек и много-много legacy. Но сам язык от этого лучше не становится — для прикладного он коряв, для системного — тяжел.
VCL, кстати, как библиотека так себе — но для Дельфи есть JEDI (даром) и DevExpress(за деньги).
Корявым же инструментом являются сами плюсы.
Кстати, по части языковых возможностей последние плюсы превосходят последнюю Дельфи только по части метапрограммирования, но те, кому нужно именно оно на плюсах пишут разве что по крайней нужде.
Практичность плюсов — это кодогенераторы лучших компиляторов, богатый набор библиотек и много-много legacy. Но сам язык от этого лучше не становится — для прикладного он коряв, для системного — тяжел.
Qt это не совсем традиционный C++, это его некий диалект, специально ориентированный на разработку прикладного софта.
Например, в чистых плюсах нету родной поддержки сигналов/слотов, хотя данный подход в разы удобнее, чем традиционная практика callback'ов
Например, в чистых плюсах нету родной поддержки сигналов/слотов, хотя данный подход в разы удобнее, чем традиционная практика callback'ов
с++ достаточно логичный язык, поэтому трата времени на борьбу с языком — это исключительно проявление непрофессионализма программиста
с++ достаточно логичный языктолько логика у него своя. А у создателей STL логика вообще не из мира сего.
а что не так в STL?
создатели постарались разом за счет шаблонов осчастливить мир, только получились медленные контейнеры, но зато довольно мощные :)
создатели постарались разом за счет шаблонов осчастливить мир, только получились медленные контейнеры, но зато довольно мощные :)
а что не так в STL?процитирую классика
C++ leads to really really bad design choices. You invariably start using the «nice» library features of the language like STL and Boost and other total and utter crap, that may «help» you program, but causes:
— infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)
— inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.
Логика плюсов — это реализация превращения системного языка в прикладной путем наложения фич с максимальным сохранением обратной совместимости.
Результат по определению эклектичный и разношерстный.
Макросы, обычные функции, класса, исключения, шаблоны, заголовочные файлы — у каждой из этих фич своя логика и синтаксис, радикально не похожие на другие.
Так что я согласен — разработка на плюсах без крайней необходимости есть признак непрофессионализма команды разработчиков.
Результат по определению эклектичный и разношерстный.
Макросы, обычные функции, класса, исключения, шаблоны, заголовочные файлы — у каждой из этих фич своя логика и синтаксис, радикально не похожие на другие.
Так что я согласен — разработка на плюсах без крайней необходимости есть признак непрофессионализма команды разработчиков.
откройте для себя jambi — отличная вещь
нужна здесь и сейчас
Позиция ясна
когда в Дельфи появился полноценный юникод?
А что не так с Юникодом, появившимся в D2009?
Дело не в языке, а в прямоте рук программиста. Сейчас каждый кто способен написать «Hello World» на C#, например, считает себя мегасовременным программером. :) И лишь единицы могут объяснить чем один язык (из одной группы) отличается от другого и почему для конкретной задачи нужно использовать именно его.
У дельфи же просто громадное комюнити, сама среда развивается, имеется бесчисленное число продвинутых компонент, которые также поддерживаются и постоянно дорабатываются.
Дельфи еще вас всех переживет. :D
У дельфи же просто громадное комюнити, сама среда развивается, имеется бесчисленное число продвинутых компонент, которые также поддерживаются и постоянно дорабатываются.
Дельфи еще вас всех переживет. :D
К сожалению, родовая травма Делфи — это фирма Борланд, она же Инпрайз, она же ДевКо, она же КодГеар. Одно перечисление названий уже говорит само за себя. Для меня переломными стали времена выхода CBuilder 6 / Delphi 7, когда стало ясно, что контора рушится, и проект не развивается толком. Даже если сейчас они выйдут на более-менее ясный путь развития, доверие вернуть будет трудно :(
В настоящее время Delphi занимается Embarcadero, которая ее активно развивает. Например в 2009 версии добавились дженерики (они же шаблоны), в 2010 — поддержка мультитача.
Согласен, некоторые возможности запоздалые, но тут уж ничего не поделаешь)
Согласен, некоторые возможности запоздалые, но тут уж ничего не поделаешь)
Самое офигенное, что в 2009 версии добавился Юникод :0)
Юникод был впервые предложен в 1992 году, массово появился в windows NT4, которая вышла кажется в 1996 году, и через 13 лет он появился в Дельфи… офигенное развитие!
Не в Delphi, а в VCL.
Про массовое использование юникода в 96 — очень смешно.
Про массовое использование юникода в 96 — очень смешно.
Смешно или нет, но внутри NT4 уже была юникодной.
ЗЫ
Судя по тому, что я видел, в основном можно сделать вывод, что Delphi == VCL, я не слышал про другие столь мощные фреймворки для Дельфи, всякие там несчастные Лазари не в счёт.
ЗЫ
Судя по тому, что я видел, в основном можно сделать вывод, что Delphi == VCL, я не слышал про другие столь мощные фреймворки для Дельфи, всякие там несчастные Лазари не в счёт.
Травма отнюдь не родовая — роды как раз прошли блестяще, в дальшейшем уход Хейлсберга стал тяжелым ударом, но настоящий пушной зверек пришел при попытке переориентироваться на .NET.
Какой практический смысл в этих строчках?
[MyAttribute('Malcolm', 39)]
procedure MyProc(const s: string);
Зачем это может понадобится в реальной жизни?
[MyAttribute('Malcolm', 39)]
procedure MyProc(const s: string);
Зачем это может понадобится в реальной жизни?
Действительно, какой практический смысл в атрибутах?
Об этом будет более подробно в следующих переводах на примере реализации доступа к БД с помощью атрибутов.
Атрибуты — это возможность добавить любые метаданные к существующему классу.
Теперь можно делать нормальные ORM на Delphi или системы плагинов более интересные.
Теперь можно делать нормальные ORM на Delphi или системы плагинов более интересные.
Уже две разные ORM на дельфи сделал, без использования атрибутов. И даже без использования class methods, на array properties.
Я в принципе не против атрибутов, но как-то они кривовато вписаны в синтаксис…
Я в принципе не против атрибутов, но как-то они кривовато вписаны в синтаксис…
Поясняйте, где вы для себя нашли кривость, ведь для этого нужно было как минимум знать реализацию схожего средства в других языках и пользоваться им.
Это как я понимаю аналог аннотаций в Java. В Java аннотации очень полезная и очень удобная вещь… С помощью аннотаций методам, полям и классам добавляется мета-информация.
Ах если бы… Delphi варил билды под Mac OS X… :-)
Или под линукс… остаётся только мечтать, зато есть Qtcreator =)
А что там с Kylix? Помню когда он вышел я был очень рад.
Мечты скоро станут реальностью ;)
Ждём-с
Ждём-с
Откуда дровишки? Интересно бы почитать. Если Kylix воскреснет, это будет очень круто.
Официальная «дорожная карта»:
edn.embarcadero.com/article/39934
Слайд про Project Delphi «X» (сейчас уже стало известно более чёткое кодовое имя — Fulcrum)
И самое обнадёживающее:
edn.embarcadero.com/article/39934
Слайд про Project Delphi «X» (сейчас уже стало известно более чёткое кодовое имя — Fulcrum)
As we’re working on Fulcrum, the next RAD Studio release with a focus on cross-compilation for Mac and Linux
blogs.embarcadero.com/abauer/2010/01/26/38908
И самое обнадёживающее:
Project Fulcrum: Delphi on Linux and Mac in Beta
Coming soon to more public beta (hopefully)
www.delphifeeds.com/go/f/65775
FreePascal вам в руки!
Сам много кратно задаюсь вопросом, зачем вообще используют этот язык...? но в силу своей малоопытности сам на него не ответил) Только могу сказать, что Delphi не мерт, покрайне мере на територии СНГ… Все страховые компании пишут свои программы именно на Delphi…
Используют по причине достаточной мощности при хорошем быстродействии и могучей вижуальности при возможночти написания нативного приложения. А Вы что предлагаете?
Java? Необходима JRE. Нет или затруднён доступ к нативным функция оси — COM, железо, API и т.п.
С++? Необходимо писать в разы больше кода — больше трудоёмкость и трудно с вижуальностью.
.NET? Ну, не плохая альтернатива, но не позволяет писать самодостаточные приложения — приносишь на систему и оказывается, что нужно 200 метров .NET тащить, а потом ещё и интернет подключать для обновления.
Собственно всё :)
Java? Необходима JRE. Нет или затруднён доступ к нативным функция оси — COM, железо, API и т.п.
С++? Необходимо писать в разы больше кода — больше трудоёмкость и трудно с вижуальностью.
.NET? Ну, не плохая альтернатива, но не позволяет писать самодостаточные приложения — приносишь на систему и оказывается, что нужно 200 метров .NET тащить, а потом ещё и интернет подключать для обновления.
Собственно всё :)
>С++? Необходимо писать в разы больше кода — больше трудоёмкость и трудно с вижуальностью.
Вы Qt когда-нибудь видели?
Вы Qt когда-нибудь видели?
Плюсы никакими самыми лучшими библиотеками не вылечить.
Видел, но объём написанного кода и сложность программы суть есть объективная реальность :)
два раза на спор писали программы Qt против Delphi на время — написать не сложное гуёвое приложение на время. Оба раза разработка приложения на C++ занимала больше времени, получался более сложный код и нативность и юзабелость на дельфях получалась лучше — было время даже реализовать всякие плюшки, вроде всплывающих подсказок, дополнительных статус баров и т.п.
два раза на спор писали программы Qt против Delphi на время — написать не сложное гуёвое приложение на время. Оба раза разработка приложения на C++ занимала больше времени, получался более сложный код и нативность и юзабелость на дельфях получалась лучше — было время даже реализовать всякие плюшки, вроде всплывающих подсказок, дополнительных статус баров и т.п.
А я на QMLе за пару часов наваяю то, над чем вы в Дельфи будете пару дней сидеть.
Тому, кто будет это сопровождать, уже можно сочувствовать?
Хватит пиписьками мерятся, для этого есть приватные встречи.
Придите в бар и там выкладывайте ваши обоснованные факты и меряйте у кого больше.
Придите в бар и там выкладывайте ваши обоснованные факты и меряйте у кого больше.
Оно будет нативным? Со всякими вкусностями вроде динамического построения форм и т.п. :)
Себе — легко. Клиенту/заказчику — а смотря куда и для чего.
А в моей практике у клиентов бывает слабое железо, тормозные каналы и тупые юзвери. Вот тут у мелкого нативного исполняемого файла приемлемых альтернатив нет.
Сферический клиент в ваших фантазиях — возможно.
А реальный клиент оплачивает то, что ему нужно, а не то что вам хотелось бы.
Думать, что у всех есть деньги (и желание их тратить) на апгрейд железа и широкополосный интернет можно только не высовывая носа из-за МКАД или принимая свой сегмент за весь рынок.
А реальный клиент оплачивает то, что ему нужно, а не то что вам хотелось бы.
Думать, что у всех есть деньги (и желание их тратить) на апгрейд железа и широкополосный интернет можно только не высовывая носа из-за МКАД или принимая свой сегмент за весь рынок.
ради одной небольшой утилиты тягать JRE? А по инету юзверям как раздавать? Начинают плакать, что надо что-то качать и ставить, что сложно, много и лениво. А права администратора?
Полезность большого проекта стремится к нулю быстрее, чем у утилиты — последней не надо таскать кучу legacy и менее страшна конкуренция.
И я видел проекты, абстрагированные от доступных ресурсов — тихий ужас, даже если в остальном это отличный продукт.
И я видел проекты, абстрагированные от доступных ресурсов — тихий ужас, даже если в остальном это отличный продукт.
Ну тогда напишите тулзу работающую с последовательным портом или COM/OLE на Javascript и HTML :)
Или на C# и F# и попробуйте её распространять без .NET. Во многих конторах компьютеры не обновлялись со времён царя Гороха и .NET там версии 1.1 или кривой 2.0. Или классную маленькую утилитку, которая будет куча памяти для работы, а пользователи не будут понимать, почему она пытается утянуть 50 метров обновлений для .NET при установке :)
Или на C# и F# и попробуйте её распространять без .NET. Во многих конторах компьютеры не обновлялись со времён царя Гороха и .NET там версии 1.1 или кривой 2.0. Или классную маленькую утилитку, которая будет куча памяти для работы, а пользователи не будут понимать, почему она пытается утянуть 50 метров обновлений для .NET при установке :)
Ну как вы можете видеть перспективы, если ничего про Delphi не знаете?
Ух ты блин. Полезность архиваторов, оболочек, терминалов, кучи софта для работы с железом (диагностика и т.п.), расчётов чего-либо и т.п. стремиться к нулю. Собственно остаётся только коорпаративный софт и монстрические пакеты, в которых одиночному разработчику делать нечего :)
А вторая часть комментария вообще не понятно к чему. Мы и говорим, о кривости, удобстве и размере.
Виртуальная машина, кстати, абстрагирует не только от ОС, но и от железа.
А вторая часть комментария вообще не понятно к чему. Мы и говорим, о кривости, удобстве и размере.
Виртуальная машина, кстати, абстрагирует не только от ОС, но и от железа.
Это весьма нетрадиционное понимание «небольшой утилиты».
Этой программе нужен GUI и доступ к нативному API вроде всякого рода COM? :)
Аге, а через пять-десять лет этот .NET 3.0 будет поддерживаться системами? :) А нативные приложения, написанные десять лет назад под Xp/2k до сих пор у клиентов работают :)
Хотелось бы…
А заказчик-то и не знает…
Если приложение внедрено и всех устраивает, то стоять и использоваться оно будет до последнего и даже дольше.
Если приложение внедрено и всех устраивает, то стоять и использоваться оно будет до последнего и даже дольше.
только пользователи будут материться на этот продукт, если когда-нибудь увидят более удобные аналоги…
Только разработка программы может стоить денег и дешевле до последнего скупать старые блоки питания.
И пример не корректный. Подавляющее большинство корректно написанного 9...10 лет нативного софта под Win2k/XP назад замечательно работает под распоследней Win7. Зачем его переписывать?
.Net и прочая красотень ни коим боком не гарантирует, что то, что я сейчас напишу под Win7 будет хоть на чём-нибудь запускаться через 10 лет.
Более-менее верить можно только С++/Qt Delphi, т.к. они умеют создавать полностью самодостаточные приложения.
И пример не корректный. Подавляющее большинство корректно написанного 9...10 лет нативного софта под Win2k/XP назад замечательно работает под распоследней Win7. Зачем его переписывать?
.Net и прочая красотень ни коим боком не гарантирует, что то, что я сейчас напишу под Win7 будет хоть на чём-нибудь запускаться через 10 лет.
Более-менее верить можно только С++/Qt Delphi, т.к. они умеют создавать полностью самодостаточные приложения.
И что значит прокиснет? Есть тулза которая управляет АЗС. Она через сколько прокиснет? Компы будут ломаться, а тулза будет работать, пока АЗС имеет место быть. Тоже самое с любым железом. Пока железо работает софт тоже будет востребован. То же самое с прикладными программами для расчётов чего-либо.
Да, даже банальные отчёты, если не меняются зачем переделывать?
Да, даже банальные отчёты, если не меняются зачем переделывать?
Все зависит от поставленных задач и целей. Зачем для похода в магазин использовать самолет, если удобней добраться на велосипеде?
Для справки — `you` переводится как `Вы`. В оригинале было `thou`? Посмотрел — нет.
«Thou», насколько мне известно, века с 18-19 особо не употребляется, в словарях названо литературным и устаревшим и большинство людей встречает его разве что в Библии и произведениях Шекспира.
В словарях, опять же, дается перевод местоимения «you» в вариантах «вы», «вами», «вас», «вам»; «ты», «тебя», «тобой», «тебе».
В словарях, опять же, дается перевод местоимения «you» в вариантах «вы», «вами», «вас», «вам»; «ты», «тебя», «тобой», «тебе».
Перефразируюсь — обращение `ты` здесь неуместно. Автор, почему вы решили, что каждый хабраобитатель готов перейти с вами на ты?
Как топик про делфи, так сразу начинается споры о том «жив ли он или нет».
Я например не поклонник C#, вы найдите среду на которой можно быстро писать программы под Windows которые занимают от 200 кб и не требуют фреймворков? Вот именно на пальцах пересчитать…
Я например не поклонник C#, вы найдите среду на которой можно быстро писать программы под Windows которые занимают от 200 кб и не требуют фреймворков? Вот именно на пальцах пересчитать…
Я думаю если хочется странного отсутствия зависимостей вообще, то проще тогда взять чистый Си
Под винду есть еще чудная штука WTL.
И трахаться с его великолепным синтаксисом и системой типов до посинения…
А есть варианты? Сами же сказали, что без фреймворков надо. Дельфи тоже фреймворк.
Delphi — язык, VCL — фреймворк. Никто не мешает писать на чистом Delphi в стиле C без ООП и получать высокоэффективный в плане потребления ресурсов код.
А какой тогда смысл в Дельфи? В стиле Си обычно пишут на Си
Нормальный язык для прикладного программирования
Есть, конечно — использовать что-нибудь типа KOL.
Да и VCL фреймворков при выполнении не требует. В отличии от Явы с дотнетом.
Да и VCL фреймворков при выполнении не требует. В отличии от Явы с дотнетом.
А GUI тоже будете на чистом C рисовать?
Ага. Стоит одному «знающему» человеку сказать, например, «Делфи — говно», как сотни хомяков, не разобравшись в теме, начинают за ним повторять. Время идет, среда меняется и улучшается, а хомяки все твердят «Делфи — говно и умерло уже»))
Это болезнь общества, ничего тут не поделаешь(
ЗЫ: кстати такая тенденция прослеживается почти со всеми качественными продуктами. Самый яркий пример — винда. 90% людей говорят «винда маст дай, линукс форева» и продолжают пользоваться этой самой виндой))
Это болезнь общества, ничего тут не поделаешь(
ЗЫ: кстати такая тенденция прослеживается почти со всеми качественными продуктами. Самый яркий пример — винда. 90% людей говорят «винда маст дай, линукс форева» и продолжают пользоваться этой самой виндой))
А ещё все дружно кричат о массовом переходе на линукс, особенно было популярно во время фейла висты. Тем не менее у винды 95% рынка как и раньше.
в сумме думаю меньше 0,01% всех пользователей винды…
Как-то не особо много смотря на цифры продаж винды семёрки.
вы найдите среду на которой можно быстро писать программы под Windows которые занимают от 200 кб и не требуют фреймворков?А рантайм VCL сколько там весит?
Рантайм VCL включен в исполняемый файл. Его можно вынести и отдельно, но эта опция не для маленьких программ.
Есть еще «облегченные» аналоги VCL, с ними экзешник весит десятки килобайт.
Чистый он весит в сжатом виде 400-600 кб, точно не помню размера.
А если делать не рантайм (что обычно и делается в делфи), то программа в сжатом виде (UPX) занимает 200+ кб.
А что, посмотрите на QT, в сжатом виде программа со всеми библиотеками занимает 4+ мб.
Java требует 200 мб дополнительной установки, .NET языки требуют для поддержки программа фреймворка 20 мб (да и еще несуразности с версиями, 2.0, 3,5 и т.д.)
Я реально, кроме Visual Studio C++ и Студию Delphi (где кстати и С++ есть) ничего лучше для создания переносимых программ на Windows не знаю.
P.S. Все якобы недостатки, нет библиотек каких-то встроенных, ну бред просто, зайдите на torry.net, разуньте глаза, для того же QT компонентов на порядок меньше, раз в 20 наверное. Я еще ни для одно среды не видел столько дополнений.
А если делать не рантайм (что обычно и делается в делфи), то программа в сжатом виде (UPX) занимает 200+ кб.
А что, посмотрите на QT, в сжатом виде программа со всеми библиотеками занимает 4+ мб.
Java требует 200 мб дополнительной установки, .NET языки требуют для поддержки программа фреймворка 20 мб (да и еще несуразности с версиями, 2.0, 3,5 и т.д.)
Я реально, кроме Visual Studio C++ и Студию Delphi (где кстати и С++ есть) ничего лучше для создания переносимых программ на Windows не знаю.
P.S. Все якобы недостатки, нет библиотек каких-то встроенных, ну бред просто, зайдите на torry.net, разуньте глаза, для того же QT компонентов на порядок меньше, раз в 20 наверное. Я еще ни для одно среды не видел столько дополнений.
Рантайм любой библиотеки это мелочь по сравнению с тем объемом мультимедийной информации, что на компе находится. Вес рантайма становится критически важным только когда ресурсов катастрофически нехватает.
В Qt меньше компонентов это да, а вот возможностей больше, вот такой вот парадокс. Но отсутствие готовых компонентов обычно пугает лишь тех, кто привык мышкой программировать. В целом же для полноценной и счастливой жизни в Qt достаточно готовых решений. Хотите больше? Ну юзайте дополнительные либы или вообще возможности kdelibs и plasma.
А из ключевых особенностей: в Дельфи напрочь отсутствует аналог QML, там невнятная интернационализация, я не нашел никаких аналогов Qtшной State машине, которая просто чудеса творит.
В Qt меньше компонентов это да, а вот возможностей больше, вот такой вот парадокс. Но отсутствие готовых компонентов обычно пугает лишь тех, кто привык мышкой программировать. В целом же для полноценной и счастливой жизни в Qt достаточно готовых решений. Хотите больше? Ну юзайте дополнительные либы или вообще возможности kdelibs и plasma.
А из ключевых особенностей: в Дельфи напрочь отсутствует аналог QML, там невнятная интернационализация, я не нашел никаких аналогов Qtшной State машине, которая просто чудеса творит.
QML — это что и зачем?
Кстати, вы продолжаете сравнение Qt с Дельфи чисто для троллинга или в самом деле не догоняете, что язык с библиотекой сравнивать никакого смысле нет?
Кстати, вы продолжаете сравнение Qt с Дельфи чисто для троллинга или в самом деле не догоняете, что язык с библиотекой сравнивать никакого смысле нет?
QML — Qt Markup Language
Основанный на экма-скрипте язык для описания динамического графического представления.
Рассматривать язык без его библиотек — это изначально бесполезное занятие, ибо толку от того же Delphi было бы без всех его компонент? или от Java без уже написанных для него фреймворков?
Основанный на экма-скрипте язык для описания динамического графического представления.
Рассматривать язык без его библиотек — это изначально бесполезное занятие, ибо толку от того же Delphi было бы без всех его компонент? или от Java без уже написанных для него фреймворков?
Понятно — в Дельфи такой нафиг не нужен. Там где не хватит dfm — ословый ActiveX всегда на месте. И лишних языков не надо.
Рассматривать язык без библиотек очень даже имеет смысл — многие недостатки языка библиотеками не исправить в принципе.
Вдобавок господин эксперт просто не в курсе, что для Дельфи есть не только голый VCL.
Рассматривать язык без библиотек очень даже имеет смысл — многие недостатки языка библиотеками не исправить в принципе.
Вдобавок господин эксперт просто не в курсе, что для Дельфи есть не только голый VCL.
Ословый activeX? Лишних языков? О.о Ужс…
Эти самые «лишние языки» в виде javascript'а очень легко позволяют описывать логику тех частей системы, где не нужно обрабатывать много данных с одной стороны, а с другой стороны нужно иметь возможность быстро менять поведение, причем прямо в рантайме. И это пример отличного симбиоза между статическими и динамическими языками.
Эти самые «лишние языки» в виде javascript'а очень легко позволяют описывать логику тех частей системы, где не нужно обрабатывать много данных с одной стороны, а с другой стороны нужно иметь возможность быстро менять поведение, причем прямо в рантайме. И это пример отличного симбиоза между статическими и динамическими языками.
Чего ужасаться? Ословый ActiveX на Win32 есть всегда. И он держит и HTML и CSS и яваскрипт.
Тот самый симбиоз, который к тому же не зависит от библиотек.
Тот самый симбиоз, который к тому же не зависит от библиотек.
Не зависит от библиотек? О.о Вы в своем уме? О.о Хотите сказать, что он как манна небесная вам на голову падает? А если Дельфийцы наконец выпустят VCL для Макоси вы как будете переносить своё «творение»?
И это вовсе не симбиоз, а гибрид костыля с граблями. Не говоря уже о том, что Trident весьма паршивый движок с тормозным яваскриптом и кривым cssом.
К тому же QML работает вообще без браузерного движка, используя от него лишь javascript часть.
И это вовсе не симбиоз, а гибрид костыля с граблями. Не говоря уже о том, что Trident весьма паршивый движок с тормозным яваскриптом и кривым cssом.
К тому же QML работает вообще без браузерного движка, используя от него лишь javascript часть.
Вы еще зависимости от платформы и библиотек не различаете? ;)
Если программа не линкуется с какой-то библиотекой, то это вовсе не значит, что она то неё не зависит. Хотите сказать ваш activeX компонент не зависит от Trident либы?
Сначала надо найти живой Win32 без Trident — потом уже говорить о зависимости от библиотеки, а не платформы.
А чего там ЕС так хочет и чего они таки добились, не напоминать?
Нет — для того чтобы заявить о зависимости именно от библиотеки надо предъявить реальный живой Win32 без Trident (не браузера IE!)
Вот из за таких «деятелей» и нету таких примеров. Если уж и юзаете платформозависимые части, то не юзайте их везде где попало по коду, а сделайте обёртку, адаптер, что угодно. Нет блин нужно лепить напрямую зависимость от компонента, API взаимодействия с которым еще и поменяться может в любой момент.
Необходимость обвешивать пользовательское приложение тонной мультимедийного добра имеется далеко не всегда. Что стоит у заказчика помимо сделанной нами программы — его дело.
10 лет не писать ничего на Дельфи и использовать аргументы «я там не нашел» — это от высокого профессионализма?
10 лет не писать ничего на Дельфи и использовать аргументы «я там не нашел» — это от высокого профессионализма?
Java требует 200 мб дополнительной установки16MB www.java.com/en/download/manual.jsp
NET языки требуют для поддержки программа фреймворка 20 мбКоторые в Vista и W7 искаробки
да и еще несуразности с версиями, 2.0, 3,5 и т.д.несурзности у Вас в голове от незнания матчасти
Я реально, кроме Visual Studio C++ и Студию Delphi (где кстати и С++ есть) ничего лучше для создания переносимых программ на Windows не знают.е. при выборе инструментария для разработки приложений под Win Вы ориентируетесь на конечный размер исполнимого файла? А Вы вообще что-нибудь серьезное разрабатывали? Обычно ресурсы к программе занимают столько, что лишних 20 мб библиотек уже никто не считает
QT компонентов на порядок меньше, раз в 20 наверноеКак же люблю делфятников с их «компонентами», а особенно тот момент, как они бесятся, когда нужный компонент не находят.
Раз в 20 меньше компонент? А ну-ка подсчитай качество и колличество библиотек на C++/Java/C# vs. Delphi.
P.S.: на дворе 2010 год – размер исполнимого файла всем по бую
У меня все проекты на Delphi с 2001г.
Сейчас последний из развивающихся (толстый клиент «всё в одном»):
1. Client-Server для соединения с Firebird
2. Разделение пишущих/читающих транзакций и механизм двухфазных транзаций
3. Встроенный редактор отчётов
4. Встроенный интерпретатор Pascal / C / JAVA
5. Импорт документов формата MS Excel без использования внешних компонент (OLE и иже с ними)
6. Экспорт документов в PDF / XLS / RTF / HTML / TXT / CSV и ещё фиг знает куда, всё не припомнить — тоже без внешней мишуры
7. Генерация, автообновление, сервис БД
8. Связки со всяким специализированным софтом (перечислять нет смысла)
9. Сотни тысяч строк кода и десятки самописных компонентов
Так вот. Исполняемый файл (ака EXE-шник) весит ~20Mb (5Mb после ASPack'а) и работает абсолютно автономно, из сторонних библиотек требуя только либу для связи с Firebird сервером (450Kb) или либу внедрённого сервера Firebird Embedded (2.7Mb).
И да, 200к — это тоже реально. И даже не 200. Писал генератор словарей в своё время (важен был размер), получалось что-то около 50к без сжатия, но писал без использования VCL (KOL + MCK). Было время, на KOL даже троянов писали, и это в эпоху дайлапа.
Так что не надо тут рассказывать про монструозность выхлопа и неподъёмность библиотек. Если есть прямые руки и инструмент хорошо знаешь — продукт будет качественный, а если научился писать «Hello world» в двух десятках новомодных сред — это ещё не значит что ты кулпрограммер.
И да, я проприетарщик, можете набрасываться — я сегодня добрый.
Сейчас последний из развивающихся (толстый клиент «всё в одном»):
1. Client-Server для соединения с Firebird
2. Разделение пишущих/читающих транзакций и механизм двухфазных транзаций
3. Встроенный редактор отчётов
4. Встроенный интерпретатор Pascal / C / JAVA
5. Импорт документов формата MS Excel без использования внешних компонент (OLE и иже с ними)
6. Экспорт документов в PDF / XLS / RTF / HTML / TXT / CSV и ещё фиг знает куда, всё не припомнить — тоже без внешней мишуры
7. Генерация, автообновление, сервис БД
8. Связки со всяким специализированным софтом (перечислять нет смысла)
9. Сотни тысяч строк кода и десятки самописных компонентов
Так вот. Исполняемый файл (ака EXE-шник) весит ~20Mb (5Mb после ASPack'а) и работает абсолютно автономно, из сторонних библиотек требуя только либу для связи с Firebird сервером (450Kb) или либу внедрённого сервера Firebird Embedded (2.7Mb).
И да, 200к — это тоже реально. И даже не 200. Писал генератор словарей в своё время (важен был размер), получалось что-то около 50к без сжатия, но писал без использования VCL (KOL + MCK). Было время, на KOL даже троянов писали, и это в эпоху дайлапа.
Так что не надо тут рассказывать про монструозность выхлопа и неподъёмность библиотек. Если есть прямые руки и инструмент хорошо знаешь — продукт будет качественный, а если научился писать «Hello world» в двух десятках новомодных сред — это ещё не значит что ты кулпрограммер.
И да, я проприетарщик, можете набрасываться — я сегодня добрый.
1. вообще-то я просто спросил сколько весит VCL
2.
3.
4.
5.
2.
Встроенный интерпретатор Pascal / C / JAVAИнтересно бы на это посмотреть
3.
Так вот. Исполняемый файл (ака EXE-шник) весит ~20Mb (5Mb после ASPack'а) и работает абсолютно автономно, из сторонних библиотек требуя только либу для связи с Firebird сервером (450Kb) или либу внедрённого сервера Firebird Embedded (2.7Mb).Ну молодец, я очень за тебя рад. Только вот размер исполнимого файла в 2010 году уже не так важен.
4.
И да, 200к — это тоже реально. И даже не 200. Писал генератор словарей в своё время (важен был размер), получалось что-то около 50к без сжатия, но писал без использования VCL (KOL + MCK). Было время, на KOL даже троянов писали, и это в эпоху дайлапа.А на C++ + MFC(или чё там винде?) наверное было бы еще меньше. Правда эпоха диалапа закончилась
5.
И да, я проприетарщик, можете набрасываться — я сегодня добрый.Да с чего бы? Я сам не особый фанат опенсорса
> Только вот размер исполнимого файла в 2010 году уже не так важен.
Это вы нашему заказчику расскажите.
Это вы нашему заказчику расскажите.
Ну и пусть такие неадекватные заказчики в лес идут. Одно дело для ebedded разрабатывать приложения, другое дело обычную прикладуху. И кстати на Дельфи вообще ebedded разработка невозможна в принципе — нет поддержки ничего, кроме костыльной x86
>Это вы нашему заказчику расскажите.
приношу свои соболезнования вашему горю и лучи поноса вашему заказчику
приношу свои соболезнования вашему горю и лучи поноса вашему заказчику
вообще-то я просто спросил сколько весит VCL
Никогда не задавался таким вопросом ибо не вижу в этом необходимости. Какой именно размер вас интересует? Исходников, скомпилированных либ или довесок к выхлопу? В любом случае это зависит от применяемых компонент. Библиотека модульная и при динамической компиляции нет необходимости поставлять все бинарники в комплекте.
Был проект в 2003г. там использовалась система плагинов моей разработки. Система корректно работала только при динамической компиляции. Основной модуль программы весил 800K, плагины по 20-100K а комплект библиотек, необходимый для работы всего этого хозяйства весил около 40M.
Встроенный интерпретатор Pascal / C / JAVA
Зачем изобретать велосипед, когда в продаже внедорожники?
fast-report.com/ru/products/fast-script.html
Ну молодец, я очень за тебя рад. Только вот размер исполнимого файла в 2010 году уже не так важен.
Правда эпоха диалапа закончилась
Вы это скажите тем, кто живёт вдали от города миллионника и качает еженедельные обновления по GPRS (современному диалапу).
Ах вот еще вспомнил. В Дельфи же до сих пор нету поддержки x86-64!
это еще фигня. А вот переменные в var объявлять куда страшнее
Ну это еще одна тема для холиворов. Это требование удобно при обучении, но в реальных проектах только мешает
Если вы боитесь объявлять переменные в var — значит вы не умеете разбивать код на короткие подпрограммы.
Я вот например не хочу, чтобы временная переменная была каким-либо образом доступна вне тела цикла, где она реально используется. И как мне такое в вашем Object Pascal'е сделать?
Это недостаток, но для коротких подпрограмм — незначительный.
тут понимаете в чем дело, далеко не всегда можно процедуру сделать небольшой. А когда и можно, то чаще всего это не имеет смысла(стоит выделять кусок кода в отдельную процедуру только тогда, когда он используется в нескольких разных других продедурах)
Процедура прежде всего — средство декомпозиции задачи на более мелкие и только во вторую очередь — средство повторного использования кода. Если ее нельзя сделать небольшой — то вам не хватает мастерства.
Так он и был популярнее их обоих вместе взятых, пока Борланд не занимался суицидом.
И вообще от производителя зависит очень много — тот же Visual Basic (когда-то самый популярный инструмент прикладников) был удавлен не разработчиками, а мелкомягкими.
Экономические законы как раз определяют, что популярность инструмента зависит от его качества весьма косвенно.
И вообще от производителя зависит очень много — тот же Visual Basic (когда-то самый популярный инструмент прикладников) был удавлен не разработчиками, а мелкомягкими.
Экономические законы как раз определяют, что популярность инструмента зависит от его качества весьма косвенно.
Это мизер — зверские тормоза при компиляции плюсового кода увеличивают стоимость разработки на несколько порядков сильнее.
Купите себе уже нормальный 2х или 4х ядерник. Время компиляции там очень даже оправданное и не такое уж и большое. Основная масса времени тратится на раскручивание шаблонов и всякие сложные оптимизации.
А если вы только и умеете, что весь проект завязывать от частоменяемого хедера, не умеете юзать предварительное объявление, не слышали про pch, то это уже лично ваш гемморой
А если вы только и умеете, что весь проект завязывать от частоменяемого хедера, не умеете юзать предварительное объявление, не слышали про pch, то это уже лично ваш гемморой
Есть небольшая проблема — у меня уже есть нормальное железо дома и на работе, я отключаю сложные оптимизации — в дебажной версии они ни к чему (скорость сборки релиза не волнует), только сколь угодно оптимизированный по сборке плюсовый проект безбожно сливает на порядок большему по размерам (и никак в этом плане не заточенному) дельфийскому.
Скорость компиляции и сборки на плюсах «оправдана» архаичными заголовочными файлами, архаичными форматами объектных файлов, кошмарным для любого парсера синтаксисом, принципиально медленной в реализации спецификацией шаблонов. В результате, значительно более сложный, написанный куда более квалифицированными разработчиками, активно использующий многопоточность компилятор с плюсов после дельфи бесит своей тормознутостью.
Скорость компиляции и сборки на плюсах «оправдана» архаичными заголовочными файлами, архаичными форматами объектных файлов, кошмарным для любого парсера синтаксисом, принципиально медленной в реализации спецификацией шаблонов. В результате, значительно более сложный, написанный куда более квалифицированными разработчиками, активно использующий многопоточность компилятор с плюсов после дельфи бесит своей тормознутостью.
Бенчмарк в студию или не было.
Эти самые «архаичные заголовки» очень удобны для чтения, это как заглавие книги. Открыл и примерно представляешь, что там. А для того, чтобы не плодить лишние инклуды, придумали предварительное объявление, которое означает, что «девки будут позже». В чем архаичность формата объектных файлов? Причем хочу видеть обоснование по каждому из компиляторов. (да я в курсе про недостаток в виде отсутствия стандартного ABI).
Что там кошмарного, MFC проекты по ночам читаете? Вот для брейнфака компилятор вообще быстрый как понос, почему же вы на нём не пишете?
Шаблоны да, принципиально сложная штука, ибо это препроцессор на стероидах, каждый шаблон разворачивается в новый сырец. Но это оправдано скоростью работы этих самых шаблонов. Они позволяют производить с кодом весьма сложные оптимизации. А еще я вам открою страшную тайну, что gcc в Линуксе или Макоси в разы быстрее плюсовый код компилит, поэтому все претензии к виндовым компиляторам.
Эти самые «архаичные заголовки» очень удобны для чтения, это как заглавие книги. Открыл и примерно представляешь, что там. А для того, чтобы не плодить лишние инклуды, придумали предварительное объявление, которое означает, что «девки будут позже». В чем архаичность формата объектных файлов? Причем хочу видеть обоснование по каждому из компиляторов. (да я в курсе про недостаток в виде отсутствия стандартного ABI).
Что там кошмарного, MFC проекты по ночам читаете? Вот для брейнфака компилятор вообще быстрый как понос, почему же вы на нём не пишете?
Шаблоны да, принципиально сложная штука, ибо это препроцессор на стероидах, каждый шаблон разворачивается в новый сырец. Но это оправдано скоростью работы этих самых шаблонов. Они позволяют производить с кодом весьма сложные оптимизации. А еще я вам открою страшную тайну, что gcc в Линуксе или Макоси в разы быстрее плюсовый код компилит, поэтому все претензии к виндовым компиляторам.
> Бенчмарк в студию или не было.
А губозакаточную машинку в комплект не приложить?
Ну что же, ты сам этого хотел ;)
Сборка (компиляция плюс линковка) с нуля (прекомпилирована только RTL и VCL) проекта на 3 тысячи строк идет мгновенно.
На 107 тысяч строк — 5 секунд.
На 330 тысяч строк — 15.
Железо — 3 гига памяти, E2200.
Delphi 2007.
> Эти самые «архаичные заголовки» очень удобны для чтения, это как заглавие книги. Открыл и примерно представляешь, что там. А для того, чтобы не плодить лишние инклуды, придумали предварительное объявление, которое означает, что «девки будут позже».
Для этих целей заголовки — жалкое подобие секции interface в дельфи.
> В чем архаичность формата объектных файлов?
В гугле забанили?
> Причем хочу видеть обоснование по каждому из компиляторов.
Нужна вторая губозакаточная машинка?
> Что там кошмарного, MFC проекты по ночам читаете?
Черным по белому написано «кошмарный для парсера» (для человека всего лишь трудный). А читал я это у разработчика компилятора.
> Шаблоны да, принципиально сложная штука, ибо это препроцессор на стероидах
… реализованный в плюсах трансректально. Сунуть в типизированный язык нетипизированные лямбды с кошмарным синтаксисом уже не только для парсера, но и для человека — такое надо суметь. Забавнее всего, что это получилось не специально.
Как это делается нормально — гуглить LISP и Nemmerle.
Спору нет — метапрограммирование полезная вещь, иногда даже очень, но кривость данной конкретной реализации убивает процентов 90 плюшек.
>А еще я вам открою страшную тайну, что gcc в Линуксе или Макоси в разы быстрее плюсовый код компилит, поэтому все претензии к виндовым компиляторам.
Скорее всего к виндовой работе с диском или к рантайму (MinGW ЕМНИП за отсутсвием своего юзает мелкомягкий). Собственно компиляции тормозить под виндой оснований нет. Только это ничего не меняет — под виндой тоже надо разрабатывать приложения. И дельфи догнать «несколько раз» не поможет.
А губозакаточную машинку в комплект не приложить?
Ну что же, ты сам этого хотел ;)
Сборка (компиляция плюс линковка) с нуля (прекомпилирована только RTL и VCL) проекта на 3 тысячи строк идет мгновенно.
На 107 тысяч строк — 5 секунд.
На 330 тысяч строк — 15.
Железо — 3 гига памяти, E2200.
Delphi 2007.
> Эти самые «архаичные заголовки» очень удобны для чтения, это как заглавие книги. Открыл и примерно представляешь, что там. А для того, чтобы не плодить лишние инклуды, придумали предварительное объявление, которое означает, что «девки будут позже».
Для этих целей заголовки — жалкое подобие секции interface в дельфи.
> В чем архаичность формата объектных файлов?
В гугле забанили?
> Причем хочу видеть обоснование по каждому из компиляторов.
Нужна вторая губозакаточная машинка?
> Что там кошмарного, MFC проекты по ночам читаете?
Черным по белому написано «кошмарный для парсера» (для человека всего лишь трудный). А читал я это у разработчика компилятора.
> Шаблоны да, принципиально сложная штука, ибо это препроцессор на стероидах
… реализованный в плюсах трансректально. Сунуть в типизированный язык нетипизированные лямбды с кошмарным синтаксисом уже не только для парсера, но и для человека — такое надо суметь. Забавнее всего, что это получилось не специально.
Как это делается нормально — гуглить LISP и Nemmerle.
Спору нет — метапрограммирование полезная вещь, иногда даже очень, но кривость данной конкретной реализации убивает процентов 90 плюшек.
>А еще я вам открою страшную тайну, что gcc в Линуксе или Макоси в разы быстрее плюсовый код компилит, поэтому все претензии к виндовым компиляторам.
Скорее всего к виндовой работе с диском или к рантайму (MinGW ЕМНИП за отсутсвием своего юзает мелкомягкий). Собственно компиляции тормозить под виндой оснований нет. Только это ничего не меняет — под виндой тоже надо разрабатывать приложения. И дельфи догнать «несколько раз» не поможет.
Знаете, раз уж бросаетесь громкими словами, извольте обосновать.
>Собственно компиляции тормозить под виндой оснований нет. Только это ничего не меняет — под виндой тоже надо разрабатывать приложения. И дельфи догнать «несколько раз» не поможет.
Но только вот Qt при помощи minGW или MSVS компилится целиком 4 часа, а в gcc под виндой или Макосью 1,5 часа или даже меньше, и это со всеми тяжёлыми штуками вроде вебкита.
>Собственно компиляции тормозить под виндой оснований нет. Только это ничего не меняет — под виндой тоже надо разрабатывать приложения. И дельфи догнать «несколько раз» не поможет.
Но только вот Qt при помощи minGW или MSVS компилится целиком 4 часа, а в gcc под виндой или Макосью 1,5 часа или даже меньше, и это со всеми тяжёлыми штуками вроде вебкита.
Пока что громкими словами без всяких обоснований здесь бросаются исключительно фанаты Qt, обсирающие инструмент, в котором они разбираются как свинья в апельсинах. А уж при заявлениях про «оправданность» времени компиляции библиотеки в часах Петросян отдыхает. Теперь я понимаю, откуда у разработчиков qutIM столько времени на флуд — за время сборки их проекта успешно пишется несколько десятков комментариев.
простая арфиметика — у тебя комментариев в топике на 20% больше, чем у нас вместе взятых :) где-то в логике фейл
Да, кстати, если делать не build, а make — то практически любой дельфи-проект собирается не более 3 секунд (обычно мгновенно), причем львиную долю времени есть линковка.
Я уже сказал, проект любых размеров на brainfuck'е будет мгновенно собираться
Ну да, аргументов по теме не осталось, приходится в очередной раз съезжать с темы
Ну значит там с оптимизациями швах. Плюсовый код с -O0 тоже реактивно билдится. А почему плюсовый код дольше Сишного билдится уже говорилось. А уж если включить профилирование и дополнительные экстра оптимизации, то билдится еще дольше станет. И чего? TCC, к примеру, вообще на лету исполняет сишный код в режиме интерпретатора и весьма шустро, но оптимизаций там по нулям, вот только где там тормоза из за «архаичных заголовочных файлов»?
Всё равно при обычных изменениях в проекте всё пересобирается секунды за 2-3, а долгий первый билд можно и пережить.
Всё равно при обычных изменениях в проекте всё пересобирается секунды за 2-3, а долгий первый билд можно и пережить.
Так сколько времени собирается отладочная версия твоего проекта, о любитель требовать бенчмарков в студио?
Ну минуты 2-10 (в зависимости от компилятора и платформы)
Что и следовало доказать — плюсовый компилятор и линкер примерно на два десятичных порядка тормознее дельфового. Для скорости и стоимости разработки это существенный недостаток. Честно не понимаю: ну нравятся тебе плюсы с Qt — так пусть и дальше нравятся, есть у них несомненные достоинства, но как можно не замечать недостатков и поливать другой инструмент по опыту десятилетней давности?
Почему-то из дельфистов очень мало кто комментирует статьи о других продуктах в уничижительном тоне и считает свой инструмент идеалом во всем.
Почему-то из дельфистов очень мало кто комментирует статьи о других продуктах в уничижительном тоне и считает свой инструмент идеалом во всем.
Существенный недостаток это для владельцев всяких нищебродских железок. Я уже сказал, что в процессе разрабьтки, все изменения пару секунд компилятся.
Увы, но в твоих статьях я только и видел, что бессмысленное поливание крестов.
В общем всем чмоке в этом чате!
Увы, но в твоих статьях я только и видел, что бессмысленное поливание крестов.
В общем всем чмоке в этом чате!
Так если ты на кресты свои молишься — то тебе любая критика сойдет за ересь. А в ответ на конкретные факты ты только хамишь и минусуешь. И в топики по дельфи не первый раз приходишь написать очередную злобную глупость — хотя казалось бы, на кой фиг осененному благодатью Qt дельфи? Неужели зависть к дельфистам виновата? :D
>Процедура прежде всего — средство декомпозиции задачи на более мелки
так в том и дело, что задача на более мелкие не разбивается, но процедура все-равно занимает 2 страницы. И не надо мне рассказывать про мастерство, бывают просто очень сложные алгоритмы.
так в том и дело, что задача на более мелкие не разбивается, но процедура все-равно занимает 2 страницы. И не надо мне рассказывать про мастерство, бывают просто очень сложные алгоритмы.
Не разбивается — значит у разработчика недостаточно мастерства в главнейшем навыке — декомпозиции задач.
«Просто очень сложные алгоритмы» нуждаются в декомпозиции сильнее всех прочих.
«Просто очень сложные алгоритмы» нуждаются в декомпозиции сильнее всех прочих.
И это мне говорит человек, который не умеет кроссплатформенные приложения делать…
я не боюсь объявлять переменные в var. Просто когда в середине процедуры мне необходимо для каких-либо целей(чаще всего дебаг или какой-нибудь маленький эксперимент) то лезть ради этого в var это какое-то издевательство
Если процедура маленькая — то о каком издевательстве речь?
Если процедура большая — то это само по себе уже косяк, нуждающийся в немедленном исправлении.
Если процедура большая — то это само по себе уже косяк, нуждающийся в немедленном исправлении.
>Если процедура большая — то это само по себе уже косяк, нуждающийся в немедленном исправлении.
Косяк – это твой опыт клепания программ из формочек методом Баттон1_Клик. Если ты не сталкивался с реализацией математических алгоритмов, которые сами по себе длинные, то и не надо мне рассказывать что и как исправлять
Косяк – это твой опыт клепания программ из формочек методом Баттон1_Клик. Если ты не сталкивался с реализацией математических алгоритмов, которые сами по себе длинные, то и не надо мне рассказывать что и как исправлять
В таких ситуациях можно пользоваться горячими клавишами, закладками, сниппетами, а в последних версиях — встроенными средствами рефакторинга. Все это позволяет объявлять новые переменные буквально одним нажатием клавиш, не покидая нужный участок кода.
Также можно подключить дополнительные средства по улучшению юзабилити IDE — Castalia, cnWizards и другие — аналоги ReSharper'а для Visual Studio.
Также можно подключить дополнительные средства по улучшению юзабилити IDE — Castalia, cnWizards и другие — аналоги ReSharper'а для Visual Studio.
А зачем она так срочно нужна? Для серверов баз данных Дельфи никогда не предназначалась.
для более полного использования ресурсов системы?
Может тогда нам вообще следовало в пещерах оставаться? Если есть технология, то есть смысл её использовать.
Все 95% нормального С++/С кода сейчас компилируется на всех распространённых аппаратных платформах.
Дельфи же гвоздями прибита к x86, а то, что её не смогли отковырять от x86 за 7 лет говорит нам о том, что пациент безнадёжно болен и даже на костылях ходить не может.
Тут вовсе не в серверах дело, это просто говорит о недалёкости.
Все 95% нормального С++/С кода сейчас компилируется на всех распространённых аппаратных платформах.
Дельфи же гвоздями прибита к x86, а то, что её не смогли отковырять от x86 за 7 лет говорит нам о том, что пациент безнадёжно болен и даже на костылях ходить не может.
Тут вовсе не в серверах дело, это просто говорит о недалёкости.
Лично вам — определенно следовало. Технологии существуют не ради технологий, а для решения конкретных задач. Прикладных задач, для решения которых предназначена Дельфи и требующих при этом 64 бита я назвать не смогу. Интересно бы знать, кто сможет.
Молодцы вы ребята. С таким отношением к делу вы и летите стремительно в legacy. Вот не будет в Windows 8 отдельной 32 битной версии — сразу забегаете, как блохи на сковородке.
Думаю Интел и AMD давно рады были бы выпилить 32битный режим, чем весьма существенно упростить конструкцию процессора, но вот из за таких вот недалёких людей это невозможно.
Думаю Интел и AMD давно рады были бы выпилить 32битный режим, чем весьма существенно упростить конструкцию процессора, но вот из за таких вот недалёких людей это невозможно.
вот, блин, тролль-хомяк разбушевался. чувак, успокойся. удобнее писать на своем Qt — пжалуйста. никто же не отнимает) но есть задачи для которых делфи отлично подходит и туп тот, кто этого не понимает, имхо.
односторонний взгляд на вещи — зло
прикинь все начнут писать на Qt? да ты же без работы останешься)))
односторонний взгляд на вещи — зло
прикинь все начнут писать на Qt? да ты же без работы останешься)))
Мощей любого современного мобильника достаточно для 90% бизнес-фронтэндов. Я не могу себе представить бизнес-задачу (кроме мультимедии и развлечений), для которой необходима 64-битная архитектура.
Я вас, случаем, не шокирую, если сообщу, что во многих больших и серьезных конторах до сих пор используется техника класса пентиум-1 и матричные принтеры? Просто потому что они успешно решают поставленные задачи с минимальными затратами.
Для такого legacy дельфя очень и очень хороший инструмент разработки.
Я вас, случаем, не шокирую, если сообщу, что во многих больших и серьезных конторах до сих пор используется техника класса пентиум-1 и матричные принтеры? Просто потому что они успешно решают поставленные задачи с минимальными затратами.
Для такого legacy дельфя очень и очень хороший инструмент разработки.
О чем и речь. Где-то до сих пор софт, написанный на Cobol'е юзают.
Но я лично настолько привык вперёд идти, что для меня любой legacy инструмент априори уже мёртв. Мне больше нравится двигаться в ногу с прогрессом или даже в какой то мере пытаться заглянуть в будущее
Но я лично настолько привык вперёд идти, что для меня любой legacy инструмент априори уже мёртв. Мне больше нравится двигаться в ногу с прогрессом или даже в какой то мере пытаться заглянуть в будущее
Поздравляю — плюсы давно уже legacy
Может у вас и ваша ОС написана на Делфи?
Когда-нибудь и они станут legacy, но не сегодня и не завтра. Язык активно развивается, видели тут недавно статью про лямбды и ленивые вычисления?
Для языка есть крутейшие фреймворки. А еще даже новый компилятор пишется llvm +clang, который сам написан на плюсах. Нвидия вот мечтает о Fermi, который позволит плюсовый код на видеокарте исполнять.
Для языка есть крутейшие фреймворки. А еще даже новый компилятор пишется llvm +clang, который сам написан на плюсах. Нвидия вот мечтает о Fermi, который позволит плюсовый код на видеокарте исполнять.
А можно какой-нибудь пример такой успешной организации? Сомневаюсь, что использование такой техники (P-I, P-II) не влияет негативно на работу. Одному из моих домашних ПК как раз исполнилось 13 лет, так что я представляю, о чем речь.
Вот в нашем университете ПК как раз такого возраста, потому временами половина не работает, а со второй даже dos-way (под Windows Millenium-то) не спасает, даже если игнорировать фиолетовые мониторы. Все, кто может, ходят со своими ноутами. Думаете, университетские организации не стали хотя б чуточку продуктивнее, если б им обновляли технику?
Вот в нашем университете ПК как раз такого возраста, потому временами половина не работает, а со второй даже dos-way (под Windows Millenium-то) не спасает, даже если игнорировать фиолетовые мониторы. Все, кто может, ходят со своими ноутами. Думаете, университетские организации не стали хотя б чуточку продуктивнее, если б им обновляли технику?
Мутные фиолетовые 15" CRT на свалку, 17-19" панели сейчас недорогие. Мышки тоже меняем на оптические. Если сеть на коаксиале, меняем на UTP (если уж настолько все запущено). Для коммерческих организаций это копейки.
WinME надо было выкидывать 10 лет назад. И ставить Win2000. Линухи вообще себя прекрасно чувствуют на таких машинах.
Для «тяжелого» софта заводим сервер терминалов. Любой современный домашний комп легко потянет 20-40 юзеров в терминале.
WinME надо было выкидывать 10 лет назад. И ставить Win2000. Линухи вообще себя прекрасно чувствуют на таких машинах.
Для «тяжелого» софта заводим сервер терминалов. Любой современный домашний комп легко потянет 20-40 юзеров в терминале.
Если отойти в сторону от моего наболевшего контрпримера, интересовало конкретно:
1) В какой-такой организации (можно примеры и западных стран) используется железо более чем 10-летней давности (P-I)?
2) Какой круг задач решается на нем?
3) Насколько такое железо мешает выполнять работникам свои функции?
4) Как этому способствует Дельфи и программы, которые на нем еще напишут в будущем?
Теоретические выкладки вполне любопытны, но интересует их связь с реальностью, уж извините. :-)
1) В какой-такой организации (можно примеры и западных стран) используется железо более чем 10-летней давности (P-I)?
2) Какой круг задач решается на нем?
3) Насколько такое железо мешает выполнять работникам свои функции?
4) Как этому способствует Дельфи и программы, которые на нем еще напишут в будущем?
Теоретические выкладки вполне любопытны, но интересует их связь с реальностью, уж извините. :-)
1. Самые разные. Оптовая и розничная торговля, строительство, заводы, банки, фермы, госучреждения. В основном, это предприятия существующие десятки лет, за пределами больших и богатых городов. Про западные страны не знаю.
2. Как правило, ведение учета. Не только бухучет и зарплата, но и производственныая автоматизация — калькуляция, сметы, затраты, логистика. Плюс, всякие специфичный софт (банковский, бюджетный, итд..). То есть, все, что связано с арифметикой, таблицами и базами данных.
3. Лучше спросить, насколько помогает. Хорошо помогает. А если поставить современный 4-ядерник с 4 гигами — лучше не станет. Скорее, только пробавится проблем совместимости с имеющимся софтом и железом.
4. Дельфистов много, их в ВУЗах до сих пор готовят. Дельфийский код хорошо читаем, а компоненты значительно облегчаю жизнь. Огромное community, базы знаний. Все уже написано и разжевано, только применяй. Гимор только с разнообразием СУБД и подходов к их использованию. Лично я практикую ORM и вполне счастлив.
Хотите своими глазами посмотреть — езжайте в область, в любой городок с населением <100к, посмотрите местную газету объявлений. Требуются либо 1С, либо Delphi, либо еще какое legacy. И компы соответствующие.
2. Как правило, ведение учета. Не только бухучет и зарплата, но и производственныая автоматизация — калькуляция, сметы, затраты, логистика. Плюс, всякие специфичный софт (банковский, бюджетный, итд..). То есть, все, что связано с арифметикой, таблицами и базами данных.
3. Лучше спросить, насколько помогает. Хорошо помогает. А если поставить современный 4-ядерник с 4 гигами — лучше не станет. Скорее, только пробавится проблем совместимости с имеющимся софтом и железом.
4. Дельфистов много, их в ВУЗах до сих пор готовят. Дельфийский код хорошо читаем, а компоненты значительно облегчаю жизнь. Огромное community, базы знаний. Все уже написано и разжевано, только применяй. Гимор только с разнообразием СУБД и подходов к их использованию. Лично я практикую ORM и вполне счастлив.
Хотите своими глазами посмотреть — езжайте в область, в любой городок с населением <100к, посмотрите местную газету объявлений. Требуются либо 1С, либо Delphi, либо еще какое legacy. И компы соответствующие.
Спасибо за развернутый ответ. Действительно мало представлял, как использовать очень старые ПК. Естественно, заменить их «4-ядерниками» я и не предлагал, но обновить до приемлемого уровня мне казалось необходимым.
Да, охотно верится, что в таких областях есть много дельфийского legacy. И, пожалуй, нанимать разработчика на С++/Qt именно в таких областях, где нужен софт «дешево и сердито» и чтоб просто работал, не целесообразно.
Да, охотно верится, что в таких областях есть много дельфийского legacy. И, пожалуй, нанимать разработчика на С++/Qt именно в таких областях, где нужен софт «дешево и сердито» и чтоб просто работал, не целесообразно.
Кстати, а можно узнать для чего нанимают разработчиков Qt, кроме сопровождения старых проектов?
Плюсы все-таки любят компетентных разработчиков и не любят сжатые сроки сдачи.
Плюсы все-таки любят компетентных разработчиков и не любят сжатые сроки сдачи.
>Кстати, а можно узнать для чего нанимают разработчиков Qt, кроме сопровождения старых проектов?
Вы вообще из нашего мира? О.о Какие старые проекты, если Qt 4.0 вышла в 2005 году и была несовместима со всеми более ранними версиями Qt. И при этом 4ая версия в разы популярнее всех предыдущих.
>Плюсы все-таки любят компетентных разработчиков
Пожалуй только с этим соглашусь, но добавлю, что любой нормальный язык должен именно таких требовать, а иначе он просто утонет в потоке мусора.
Вы вообще из нашего мира? О.о Какие старые проекты, если Qt 4.0 вышла в 2005 году и была несовместима со всеми более ранними версиями Qt. И при этом 4ая версия в разы популярнее всех предыдущих.
>Плюсы все-таки любят компетентных разработчиков
Пожалуй только с этим соглашусь, но добавлю, что любой нормальный язык должен именно таких требовать, а иначе он просто утонет в потоке мусора.
Дельфистов, увы, мало — в вузах многие учатся только формально, а для легального домашнего или фрилансерского использования дельфи безбожно дорога (версии от 8 до 2007 еще изрядно глюкавы). Впрочем, уровень дельфи-разработчика растет быстро, кривая обучения пологая, переход на яву-дотнет трудностей не представляет.
Delphi 7 можно поиметь бесплатно. Это одна из самых стабильных и самая популярная до сих пор версия. Сам всё никак не перееду с неё на 2010. Китай весь сидит сейчас на D7 и радуется. Качал их сборку D7 с блек-джеком и шлюхами — основательно пересобрали и допилили VCL, повесили кучу оптимизаторов на саму среду. Получился очень таки приятненький и отлично работающий покемон :)
ЛЕГАЛЬНО бесплатно? Если да, то можно ли ссылочку?
Живую ссылку что-то не наблюдаю. Только куча битых. С переездом на Embarcadero ситуация наверное изменилась, но на CodeGear можно было заказать ключик Delphi 7 Personal бесплатно, но сам инсталлер тянуть с торрентов.
Следы от раздачи гулют: portableapps.com/node/6580
Следы от раздачи гулют: portableapps.com/node/6580
Ребята, вы забываетесь. Не всегда нужна кроссплатформенность, не всегда нужен универсальный монстр для разработки всего и вся. Для разработки калькулятора подойдет одно, а для высоконагруженного онлайн-сервиса другое средство.
Никто не ограничивает вас в выборе средств при решении задачи.
Когда человек знает одно средство лучше других и уверен в своих силах, то он решит задачу — достигнет поставленной цели, а это самое важное.
Никто не ограничивает вас в выборе средств при решении задачи.
Когда человек знает одно средство лучше других и уверен в своих силах, то он решит задачу — достигнет поставленной цели, а это самое важное.
пожалуй самый адекватный коммент из всего, что тут намусорили холиварщики)
Браво, я то же самое хотел сказать.
+ конкретно, за Delphi, добавлю, что есть организации, где половина парка машин — более, чем пятилетней давности. И писать GUI-приложения для них проще всего как раз на Delphi.
А если старый комп при запуске программы будет уходить в глубокую задумчивость на минуту-две, тут, знаете, не то чтобы стыдно, кирпичом бы по голове не получить :)
+ конкретно, за Delphi, добавлю, что есть организации, где половина парка машин — более, чем пятилетней давности. И писать GUI-приложения для них проще всего как раз на Delphi.
А если старый комп при запуске программы будет уходить в глубокую задумчивость на минуту-две, тут, знаете, не то чтобы стыдно, кирпичом бы по голове не получить :)
Если бы никто — не работодатель, так заказчик :)
Ну и собственные возможность — хочется осилить хаскель, но пока не идет.
Ну и собственные возможность — хочется осилить хаскель, но пока не идет.
Укажи список переводчиков. Зря что ли трудились?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кратко о RTTI и атрибутах в Delphi 2010