Motto

В тихом саду здравомыслия
Пусть на вас постоянно падают
кокосовые орехи пробужденности.
Чогьям Трунгпа РИНПОЧЕ


Версия для мобильного


суббота, 6 марта 2010 г.

Delphi 2011: Fulcrum. Слухи и фантазии.

Я уже публиковал крупнейший в рунете обзор нововведений в Delphi 2010, теперь пришло время взяться за Delphi 2011. =)

Update: пост изменён 20-го мая, так как предыдущий вариант содержал закрытую информацию Embarcadero. Впрочем, почти вся информация сохранилась и теперь доступна публично. Так как, к этому времени обновился roadmap, я переписал пост, основываясь на официальной официальной дорожной карте Delphi.

Что же нам обещают в "Fulcrum"

  • Кроссплатформенность, использующую технологию cross-compiler для Windows и Mac OS.
    • RAD Studio будет запускаться под Windows.
    • Особое внимание будет уделено возможности создания клиентских программ с GUI, умеющих работать с dbExpress и DataSnap
  • Удалённая отладка и деплоймент приложений для Mac OS
  • Кроссплатформенный аналог VCL
  • Полное решение/интерфейс для управления исходным кодом
  • Автоматическая генерация юнит-тестов
  • Поддержка гибкого моделирования с генерированием диаграмм последовательности (англ: sequence diagram)
  • создание REST серверов
  • Поддержка облачных вычислений: интеграция с Microsoft Azure.

А вот список того, что запланировано на последующие релизы:

  • 64-битный компилятор - 1я половина 2011 года
  • Компиляция для Linux-a - следующая версия Delphi "Wheelhouse"
  • серверная часть Datasnap для Linux и MacOS - в "Wheelhouse"
Мои комментарии:
  • Кроссплатформенный GUI для Mac OS - это наверно хорошо, но лично мне от этого ни холодно ни жарко. Лично мне в кроссплатформенности интересна только возможность писать сервера приложений, с возможностью их запуска под CentOS. И GUI там не нужен.
  • Поддержку SVN на уровне 2-х комманд (SVN Commit и Update) можно реализовать и в Delphi 2010 - но толку от неё в таком виде, имхо, не особо много. Плохо то, что существующие OpenToolsApi интерфейсы даже не позволят сделать что-то лучше. Лично я вполне сжился с TortoiseSVN и её интеграцией в IDE (через Shell Menu).
  • А вот автоматическая генерация юнит-тестов меня очень интригует.

 

А вы как думаете через сколько лет стоит ждать стабильно работающую версию Делфи с поддержкой кроссплатформенности для создания GUI приложений?

Моя версия - не раньше чем через 2-5 лет. А ваша? =)

| | | Share
Опубликовал: Aleksey Timohin в 00:39
Метки: , , ,

168 человек заметили этот пост:

  1. Они бы лучше сделали поддержку 64-битных ОС, чем эту кроссплатформенность, которая будет еще лет так 5 допиливаться.
    ОтветитьУдалить
  2. А когда допилится, никому не будет нужна, все уже перейдут на Google OS. :-)

    Насколько я понимаю, для реализации 64-битности им всё-равно пришлось бы многое переписать. Многое из того, что они сейчас делают для введения кроссплатформенности. Впрочем, это только мои предположения.
    ОтветитьУдалить
  3. АнонимныйMar 5, 2010 03:33 PM
    А по моему Delphi скоро умрет. Никто здравомыслящий на Delphi не переходит. А те кто остался, рано или поздно переходят с нее на более продвинутые средства разработки приложений.
    ОтветитьУдалить
  4. Перешел на Visual Studio. C# куда удобнее язык чем Object Pascal.
    VS грузится вообще быстро, щас попробовал (первый запуск за сегодня), ушло 2 секунды.
    Раньше я тоже, Delphi, Delphi, удобный синтаксис, все просто, посмотрел C# и понеслось, Delphi оказалась неудобной, и то что можно на WPF сделать без единой строчки кода, на Delphi пришлось бы писать ... ну-у, не мало. И это только самые простые вещи которые первыми пришли на ум.

    И я даже не собираюсь обратно на Delphi переходить.
    ОтветитьУдалить
  5. АнонимныйMar 5, 2010 10:16 PM
    Да да, а визуального наследования как не было нормально так и нет в вашей визуал студии. То что вы легко переходите, говорит лишь об уровне на котором вы работали на Delphi.
    ОтветитьУдалить
  6. Очень интересная информация, спасибо.

    По поводу будущего, туманно оно. D2007 должен быть после Delphi 7. А так время упущено, сейчас большие проекты очень проблематично перевести на 2009/2010, новые большие начинать на 2009/2010 не хочу т.к. прийдется держать 2 IDE и 2 набора компонентов.
    ОтветитьУдалить
  7. АнонимныйMar 5, 2010 11:43 PM
    Ага, а портировать приложение на НЕТ 1.1 на ВС2010 легко да? А может быть с НЕТ 2.0 легко?

    Я на работе именно все свои проекты (самый большой 500 тыс. строк кода) портировал с 2006 на 2010 удачно, все работает уже почти год. Портировал именно для того что бы пересесть на новую среду и не разводить зоопарк.

    На следующую версию - х64, кросплатформ переводить не планирую, думаю будет много гемороя, а главное особой выгоды нет.
    Вообще придерживаюсь мнения, что проекты должны поддерживаться на той версии на которой создавались, если нет особых причин (например как поддержка W7 или необходимость х64)
    ОтветитьУдалить
  8. Только что ради интереса сравнил время запуска (первый запуск за день):
    1) Голая (без сторониих либ и расширений) MS Visual C# 2010 Express запустилась за ~18 секунд.
    2) Delphi 2010 c кучей компонентов и экспертов - 22 секунды.
    ОтветитьУдалить
  9. C# действительно выглядит интересней и удобнее.
    Словно все минусы Делфей были учтены и исправлены в C#.

    А WPF в плане графической презентации рвёт визуальные Delphi-компоненты как тузик грелку.
    ОтветитьУдалить
  10. Visual Studio действительно запускается в первый раз почти мгновенно (до главного меню), НО если попытаться открыть проект или пощелкать по меню -- начинаются тормоза и приходится некоторое время ждать.
    ОтветитьУдалить
  11. АнонимныйMar 6, 2010 04:42 AM
    * Поэтому все приложения до сих пор нативные на с++ или Delphi. А в WPF как не было визуального наследования так и нет. Как копипастили формы так и будут, а мы тем временем будем наследовать формы и фреймы и собирать приложение из универсальных модулей;
    * Action как не было так и нет;
    * Грид в стандартныой поставке WinForms как был убожеством мигающим так и остался;
    * как жрало все это кучу ресурсов и тормозило так и продолжает.
    * Fetch on Demand то сделали в ADO ? А то ведь не смешно уже.
    ОтветитьУдалить
  12. Aleksey Timohin, очень странно, у меня профессиональная версия за 2 секунды запустилась. Сейчас проверил снова - в итоге 3 секунды.

    >>> А WPF в плане графической презентации рвёт визуальные Delphi-компоненты как тузик грелку.
    Что есть то есть! Суперская вешь. Это не только эффектно выглядит но и еще огромное количество плюсов дает, например простая разработка, отдельно от программиста. Т.е. дизайнер см по себе, программист сам по себе. Ну и есть инструмент для дизайнера позволяющий еще проще выполнять дизайнерские задачи.

    А насчет тормозов, у меня нету, да и если приложение написать нормально, то и у пользователей все будет отлично. Взять бы тотже VS 2010 полностью перенесенный на WPF. Ну а VS 2008 был частично с использованием WPF, работает тоже быстро и без ошибок.
    ОтветитьУдалить
  13. > C# действительно выглядит интересней и удобнее.
    Словно все минусы Делфей были учтены и исправлены в C#.

    > А WPF в плане графической презентации рвёт визуальные Delphi-компоненты как тузик грелку.

    Ну и то же теперь, неужели переходить на C#? :)
    ОтветитьУдалить
  14. > А в WPF как не было визуального наследования так и нет. Как копипастили формы так и будут, а мы тем временем будем наследовать формы и фреймы и собирать приложение из универсальных модулей;

    Copy-Paste конечно зло. Но и визуальное наследование особо удобным я бы не назвал. По крайней мере в том, что касается фреймов. Повозившись с разными багами, я перестал класть фреймы на формы в дизайнере, заменив на динамическое создание в run-time. Так намного проще контролировать ситуацию.

    Мне даже сложно представить ситуацию, когда визцальное наследование может быть полезно.
    ОтветитьУдалить
  15. Сергей, у меня не самый быстрый комп. Я лишь хочу подчеркнуть, что на моём компе, время запуска VS2010 и Delphi2010 практически одинаково.

    >Ну и то же теперь, неужели переходить на C#? :)
    Keeper, есть ещё Delphi Prism. ;)
    ОтветитьУдалить
  16. Ну вот, если будет выбор между C# и Delphi Prism - я выберу первое :)
    Речь именно об обычном Delphi. Есть же у него какие-то преимущества (или планируются)?

    > Насколько я понимаю, для реализации 64-битности им всё-равно пришлось бы многое переписать.
    Все равно мне это кажется более насущной проблемой, чем полукроссплатформенность. Средненькое приложение для Linux можно и в том же Lazarus'е сделать, а серьезное портировать думаю и не удастся. А 64-битные платформы и приложения это уже почти норма.
    ОтветитьУдалить
  17. АнонимныйMar 7, 2010 11:47 AM
    > Они бы лучше сделали поддержку 64-битных ОС, чем эту кроссплатформенность, которая будет еще лет так 5 допиливаться.

    Я думаю лучше они пусть кроссплатформенность "пилят", т.к. особо не вижу в поддержке 64-битных ОС чегото действительно нужного (производительность увеличится ~ < 10% - всего то)
    Если они "допилят" за 2 года это будет прекрасно.
    ОтветитьУдалить
  18. Анонимный - проблема 64-битности более актуальна для тех кто пишет библиотеки. 64-битные приложения не дружат с 32-битными DLL-ками.
    И не факт, что за 2 года они сумеют стабильную удобную кроссплатформенность.
    ОтветитьУдалить
  19. > Copy-Paste конечно зло. Но и визуальное наследование особо удобным я бы не назвал. По крайней мере в том, что касается фреймов. Повозившись с разными багами, я перестал класть фреймы на формы в дизайнере, заменив на динамическое создание в run-time. Так намного проще контролировать ситуацию.

    Добро пожаловать в java ))) Там ваще с GUI туго )
    ОтветитьУдалить
  20. АнонимныйMar 9, 2010 04:01 AM
    >И не факт, что за 2 года они сумеют стабильную удобную кроссплатформенность.

    Был на конференции по D2010, между тем было сообщено что большие ресурсы кинуты на это. Так что посмотрим.
    После реализации, я думаю это будет жёстким аргументом в пользу Delphi для тех кто перешёл С#
    ОтветитьУдалить
  21. >>После реализации, я думаю это будет жёстким >>аргументом в пользу Delphi для тех кто перешёл С#

    Не думаю, что это будет таким уж весомым аргументом...Linux он конечно развивается, растёт и т.д., но если взглянуть на процент пользователей которые сидят ТОЛЬКО в Linux или используют ТОЛЬКО MacOS, то можно сказать, что Embarcadero пробует выстрелить из пушки по мухе (даже не по воробью). Я конечно рад, что намечается кроссплатформенность, т.к. сейчас приходится ковыряться то в Delphi, то в Лазаре, но согласен с Keeper - лучше бы больше сил кинули на 64-битность.
    ОтветитьУдалить
  22. Ололо! Холивар! =)

    > Если я правильно понял, у автора получилось скомпилировать только консольную программу под OS X. Попытка скомпилировать GUI-программу успехом не увенчалась.
    O_O Прямо на Виндавс получилось? Не верю!

    > А вы как думаете через сколько лет стоит ждать стабильно работающую версию Делфи с поддержкой кроссплатформенности для создания GUI приложений?
    Хм... Java до сих пор ниачём в плане Native Look and Feel, а Qt уже столько лет... Вообщем, если Майя были правы, не видать вам кросс-ОС Delphi как своих ушей! =)
    ОтветитьУдалить
  23. Из плюсов Delphi к примеру:

    Такая конструкция, при вызыве, выдаст сообщение об ошибке:
    procedure TForm42.Button1Click(Sender: TObject);
    var
    i: integer;
    begin
    i:=0;
    MessageDlg(IntToStr(100 div i), mtInformation, [mbok] ,0);
    end;

    В C# приложение ещё и закроется, что может очень расстроить пользователя ;)
    private void button1_Click(object sender, RoutedEventArgs e)
    {
    int i = 0;
    MessageBox.Show((100 / i).ToString());
    }

    Причём совет использовать TRY catch блоки для меня приравнивается к совету писать программы без ошибок ;)
    ОтветитьУдалить
  24. Codegear/Embarcadero живут под девизом "Ни года без новой версии Delphi" ? Лучше бы действительно ошибки исправляли, чем каждый сервиспак называть новым именем и брать денег за апгрейд.
    ОтветитьУдалить
  25. АнонимныйMar 16, 2010 10:04 AM
    После покупки Delphi компанией Embarcadero дела пошли на поправку.

    чем лучше Delphi чем C#?
    Delphi нативный язык, C# для полускриптового дот нета. Отсюда и рога - тормоза, большие размеры и ресурсы у C# и соответсвующие ограничения на скоростные алгоритмы, на невозможность создания cgi и др. плюс обязательное наличие дотнет.
    ОтветитьУдалить
  26. Наверное повторюсь, но я до сих пор не понимаю чего они так к GUI привязались. Сделали ли бы для начала хотя бы компилятор консольных приложений/библиотек - и то было бы хорошо.

    Анонимный комментирует...
    >чем лучше Delphi чем C#?
    У разных пользователей - разные задачи. Я, например, пишу GUI для баз данных, и скоростные алгоритмы мне до фени (лишь бы работа с БД шла быстро).
    ОтветитьУдалить
  27. АнонимныйMar 18, 2010 04:15 AM
    >> Сделали ли бы для начала хотя бы компилятор консольных приложений/библиотек

    Эм, что за бред? Собственно он существует еще с самой первой версии Delphi 1 :). Хочешь пиши с GUI, а хочешь без. Хочешь компили dll. Как это можно было не заметить?
    У меня консольный cgi на сервере крутится, писал его на Delphi. Быстрый exe, - то что нужно.
    ОтветитьУдалить
  28. АнонимныйMar 18, 2010 04:20 AM
    Я представляю Fruity Loops Studio (написана на Delphi), мощная студия для создания музыки, с кучей секвенсоров, которая написана на C# - тормоза обеспечены.
    Ну или тот же фотошоп, на C#. :)
    ОтветитьУдалить
  29. Анонимный ляпнул:
    > Эм, что за бред?
    Деточка, речь идёт о кроссплатформенном консольном компиляторе, кросс-плат-фор-менном!
    ОтветитьУдалить
  30. АнонимныйMar 19, 2010 11:26 AM
    Lazarus рулит.
    ОтветитьУдалить
  31. АнонимныйMar 24, 2010 04:02 PM
    http://isdelphidead.com/

    Delphi приносит мне дофига денег. Холиворьте дальше :)
    MicroISV
    ОтветитьУдалить
  32. >>> Из плюсов Delphi к примеру
    Вы не поверите, но на самом деле это её минус.

    Это не более чем наследие старых времён, когда в программах не было глобального обработчика необработанных исключений.
    ОтветитьУдалить
  33. АнонимныйMar 30, 2010 11:56 AM
    Интересно, а в VS также легко, удобно и мощно реализована многозвенная архитектура доступа к БД? Я имею в виду что-то похожее на DataSnap. Давно использую эту технологию в проектах - просто класс. В IDE 2010 - очень сильно усилилась DataSnap. Embarcadero так держать. Кому интересно на русском не много о DataSnap: http://www.delphi2009.ru/Delphi_2010_DataSnap_RUS.pdf
    ОтветитьУдалить
  34. АнонимныйApr 1, 2010 03:46 AM
    Насчет якобы "недостатков" визуального наследования.

    Не надо смешивать визуальное наследование форм/фреймов с глюками, связанными с размещением фреймов в дизайнтайме. Подобные высказывания говорят о незнании премета.

    Не нравятся фреймы - не используем, но визуальное наследование к проблемам размещения фреймов - никаким боком.
    ОтветитьУдалить
  35. АнонимныйApr 2, 2010 09:46 AM
    Лично я верю в Embarcadero.
    Пока мелкомягкий не портирует .NEТ как JAVу - за ним нет будущего(((
    ОтветитьУдалить
  36. АнонимныйApr 26, 2010 01:39 PM
    Фигня это китайцы над delphi 2010 издеваються а разработчики 2011 невыускали
    ОтветитьУдалить
  37. > Фигня это китайцы над delphi 2010 издеваються а разработчики 2011 невыускали
    Не выпускали. Но выпустят. И UCL там будет. =)
    ОтветитьУдалить
  38. Пара ссылок на официальный сайта, где упоминается Fulcrum
    http://blogs.embarcadero.com/abauer/2010/01/26/38908
    http://cc.embarcadero.com/item/27675
    Ну а самое подробное (полу)официальное описание Фулкрума здесь:
    http://en.wikipedia.org/wiki/Borland_Delphi
    ОтветитьУдалить
  40. Веры в Дельфи у меня лично больше нет.
    Только разве что "спортивный интерес" остался.

    А так, перелез на C# и всем настоятельно советую.
    Есть у МелкоМягких свои тупости и минусы, но плюсов у VS+C#+.NET на порядок больше.

    IMHO: Последние версии Дельфей выглядят убогенько на фоне C#.
    Дельфи явно остаются в роли неудачного догоняльщика и в идеологическом и в технологическом плане.
    Крайне не рекомендовал бы начинать новые проекты на нем. К тому же и специалистов уже проблематично набрать в команду - почти вся молодежь на C# и на Жабе сидит. А что будет через пару-тройку лет?

    А вот поможет ли Дельфям кросплатформенность вылезти из полной ж...?
    - Не уверен.

    MacOS X - это все же больше не офисная платформа. Там мордочки для БД и прочий стандартный Дельфи-софт не особо востребованы.
    К тому же там есть вполне функциональный и дешевый IDE для Object-C заточенный под особенности данной OC.

    Linux - ну не знаю... по-моему это не в духе GNU GPL. Это сообщество все же живет по своим законам.
    ОтветитьУдалить
  41. АнонимныйMay 14, 2010 05:43 AM
    >чем лучше Delphi чем C#?
    Всегда сложно спорить о вкусе устриц с человеком, который их не ел.

    Может и глупо в сотый раз, но все же...
    >Delphi нативный язык, C# для полускриптового дот нета.

    Delphi - "нативный язык"? А с терминами-то у вас явная беда :)
    А .NET не "скриптовый" и не "полускриптовый". Более правильное понятие - отложенная финальная компиляция и оптимизация в конечный код платформы.
    В конечном же счете С#-повый код выполняется найтивно и при этом он очень и очень неплохо оптимизирован. Мы сравнивали финальный ASM от Дельфей и от C# - разницы ни какой. "Плавающую точку" .NET оптимизирует даже получше Дельфей.
    Кроме того можно создать и уже полностью откомпилированный (найтивный) образ.

    >Отсюда и рога - тормоза, большие размеры и ресурсы у C#

    ???
    В основном размеры, ресурсы, рога, тормоза в C# будут только от "горе-разработчиков" плохо знающих основные принципы работы с данной средой.
    Впрочем, так же, как и на Дельфях.

    >и соответсвующие ограничения на скоростные алгоритмы, на невозможность создания cgi и др.
    На скоростные алгоритмы ограничений в C# нет.
    Чисто вычислительные алгоритмы могут выполняться даже быстрее, чем на Дельфях.
    А вот cgi я бы и на Дельфях делать КРАЙНЕ не рекомендовал бы. Для cgi нужен например VC++ с его ШИКАРНОЙ оптимизацией.

    > плюс обязательное наличие дотнет.
    IMHO: Это вообще уже "детско-садовский аргумент".
    Неужели в 2010 году это кого-то может всерьез напугать, да еще и на Win платформе? ;)
    ОтветитьУдалить
  42. АнонимныйMay 14, 2010 12:22 PM
    64 бита обещают в этой версии тоесть 2011
    ОтветитьУдалить
  43. АнонимныйMay 20, 2010 05:45 AM
    >IMHO: Это вообще уже "детско-садовский аргумент".
    >Неужели в 2010 году это кого-то может всерьез >напугать, да еще и на Win платформе? ;)

    Это может напугать тех кто понимает, что для того что бы все .net проги работали им необходимы абсолютно все фрайьворки.
    ОтветитьУдалить
  44. АнонимныйMay 20, 2010 07:04 AM
    >Delphi - "нативный язык"? А с терминами-то у вас явная беда :)
    А .NET не "скриптовый" и не "полускриптовый". Более правильное понятие - отложенная финальная компиляция и оптимизация в конечный код платформы. ...

    Я х.з. , как бы ты это не называл бы "отложенная финальная компиляция" или как то иначе С#-е приложения тормознутее аналогичных делфёвых.
    Попробуйте сделать тест Заполнения массивов объектов, чтения, удаления, Больших! массивов. и Сравни. Память и Скорость.
    Как Вы думайте приложения класса Фотошопа или Корелдро реально написать на С#? и как они будут работать?))
    ОтветитьУдалить
  45. АнонимныйMay 20, 2010 07:32 AM
    Кстати "отложенная финальная компиляция и оптимизация в конечный код платформы" это и есть транслятор а соответственно "скриптовый"
    ОтветитьУдалить
  46. АнонимныйMay 22, 2010 03:05 PM
    >А по моему Delphi скоро умрет. Никто здравомыслящий на Delphi не переходит. А те кто остался, рано или поздно переходят с нее на более продвинутые средства разработки приложений.

    Интересно MS приплачивают парням, кто это пишет?
    ))
    ОтветитьУдалить
  47. АнонимныйMay 22, 2010 06:15 PM
    > Это может напугать тех кто понимает,
    > что для того что бы все .net проги работали
    > им необходимы абсолютно все фрайьворки.
    Не "пугайте ежа голой жoпой" :)
    Какие все фраимворки!?

    Будете поставлять свое приложение с инсталятором необходимого вам фреимворка.

    Вас же не пугает, что, например, все игры идут с инсталятором необходимого DirectX, а еще многие серьезные коммерческие программы написанные на VC++ идут вместе с инсталятором C++ runtime библиотек.

    Короче, ни кого это уже особо не волнует.
    За исключением вас, разумеется :)

    > Я х.з. , как бы ты это не называл бы
    > "отложенная финальная компиляция" или как то иначе
    > С#-е приложения тормознутее аналогичных делфёвых.
    Все же, прежде чем спорить по сути необходимо разобраться в понятиях. Поэтому начнем с азов:
    Так вот Delphi ни какой не "найтивный язык". Delphi(или ObjectPascal) также как и C# - языки высокого уровня реализующие парадигму ООП.
    Ты же, очевидно, имел в виду, что Delphi компилирует сразу в X86 машинный(найтивный) код.

    C# компилирует в байт-код (MSIL). Реально - это такой условный ассемблер высокого уровня.
    Перед выполнением такая программа компилируется .NET средой в конечный целевой (X86/x64 или другой) машинный код.
    Много ли это занимает времени? Поверь - нет.
    Если же тебя это время так волнует, то ты можешь создать "найтивные" (уже откомпилированные из MSIL в X86/x64) образы своего приложения на конечной машине и тогда, в твоем понимании, вообще не будет разницы между кодом порожденным Delphi и C#.
    Более того, для некоторых алгоритмов конечный X86 код порожденный .NET может быть даже более оптимальным, чем Дельфевый.

    А вот когда ты говорил про "полускриптовый .NET", ты, возможно, имел в виду не компилятор, а скриптовый интерпретатор. Так вот в этом-то ты и не прав.


    > Попробуйте сделать тест Заполнения массивов объектов,
    > чтения, удаления, Больших! массивов. и Сравни. Память и Скорость.

    А вот, что касается принципов работы с памятью - это уже совсем другой вопрос.
    Но прежде чем ставить подобные эксперименты и потом что-то утверждать, неплохо бы вам представлять себе детали и разницу в механизмах выделения и освобождения памяти в этих двух средах, поскольку, на самом деле, это очень объемный вопрос.
    А так, для примера, если вам нужны быстрые и большие массивы на C# вы можете, например, размещать их в стеке (stackalloc). Доступ к данным будет еще быстрее, чем на дельфях.
    Если же вам нужна не память, а именно "массивы объектов", то здесь еще "бабушка на двое сказала".
    Для определенных задач .NET "мусорщик" работающий в параллельном потоке может оказаться куда более эффективным средством, чем дельфевый менеджер памяти, который к тому же имеет серьезные проблемы в работе при написании многопоточных DLL (приходилось сталкиваться).

    >Как Вы думайте приложения класса Фотошопа или Корелдро реально написать на С#?
    >и как они будут работать?))

    Подобные приложения крайне не желательно писать как на С#, так и на Delphi.
    Только C++, C++ и еще раз C++

    Delphi и C# - это, прежде всего, RAD-среды. Использовать их по другому назначению - не целесообразно.
    Но вот как раз-таки как RAD среда C# и обогнал Дельфи, причем существенно.
    Именно поэтому-то, а не по чему-то другому Дельфи и загибаются.
    ОтветитьУдалить
  48. >>> Я х.з. , как бы ты это не называл бы "отложенная финальная компиляция" или как то иначе С#-е приложения тормознутее аналогичных делфёвых.

    Как правильно заметил другой анонимус, это показатель того, что вы не знаете среду, в которой работаете. Примерно так же, как если бы вы создали массив из нескольких тысяч объектов размером 12 байт в Delphi и ругались бы, что это в 15-20 раз тормознее "аналогичного" кода C (где были использованы аналоги дельфёвых record-ов).

    .NET - это именно нативный код. Только компилируется он на целевой машине, а не машине разработчика, что и обеспечивает его кроссплатформенность.
    ОтветитьУдалить
  49. АнонимныйMay 26, 2010 02:48 AM
    что и обеспечивает его кроссплатформенность - ? Где? на Мас, на Lin, ... N, или Только Win32, Win64. Какая хорошая кросс, меж платформенность. )))
    ОтветитьУдалить
  50. АнонимныйMay 26, 2010 02:52 AM
    > Подобные приложения крайне не желательно писать как на С#, так и на Delphi.

    Подобные вещи можно писать на Delphi. И будут они работать ровно. (С учётом грамотного программиста)
    ОтветитьУдалить
  51. АнонимныйMay 26, 2010 03:02 AM
    >Если же тебя это время так волнует, то ты можешь создать "найтивные" ...

    Господа, как Вы думайте почему MS не пишет свои проложения на .Net, {ведь С# же довольно приличный язык , современный, удобный, кроссплатформенный, разраб. с 2001 года (уже почти 10 лет)}, типа Word, Excel, ... N ( только шарепоит на нём из тех чем я пользуюсь) ?
    Или всётаки он для определенного класса приложений?
    ОтветитьУдалить
  52. > Господа, как Вы думайте почему MS не пишет свои проложения на .Net,

    Вообще-то пишет. А дедушка MS Office наверное имеет слишком большую и отлаженную базу кода, чтобы её просто так брать и выбрасывать переписывая на новой платформе.
    ОтветитьУдалить
  53. > Господа, как Вы думайте почему MS не пишет свои проложения на .Net

    Как вы себе представляете перенос проектов с 20-летней историей, огромной базой кода и кучей хаков совместимости под .NET?
    ОтветитьУдалить
  54. АнонимныйMay 26, 2010 04:18 AM
    > Где? на Мас, на Lin, ... N, или Только Win32, Win64. Какая хорошая кросс, меж платформенность. )))

    Я бы вас еще отчасти понял, если бы иронизировали будучи адептом Java.
    Но на Дельфях вы и для x64 пока написать ничего не в состоянии (вас пока все "завтраками кормят"), не говоря уже о более актуальных проблемах - наладонники, специализированные мобильные устройства с WinMobile, WEB и т.д. т.п.
    Мы пока на С# не перелезли, года три тому назад даже вынуждены были заказывать модуль для наладонника на стороне. Теперь вот сами справляемся.

    > Подобные вещи можно писать на Delphi.
    > И будут они работать ровно. (С учётом грамотного программиста)
    Нет, вы конечно можете выпендриться, как впрочем и на C#
    Но не забывайте, что для таких приложений вам понадобится очень высокий уровень оптимизации и с учетом SSE. На Дельфи это будет проблематично, если только вы не планируете половину кода писать на встроенном ассемблере.
    А сам Дельфи вообще очень средненько оптимизирует в машинный код (иногда, на порядок хуже VС++)

    > Или всё-таки он для определенного класса приложений?
    Совершенно верно. Так и говорили уже.
    Что Delphi, что C# - это прежде всего средства для Rapid Application Development (RAD), а не средства для системного программирования.

    Просто, последнее время на C# стало писать проще и удобнее и системы классов и "бизнес-логику", и "морды". Даже языковые конструкции для повседневных задач IMHO более удобные и лаконичные. Одни "лямбда выражения" в рамках системы обобщенных классов чего стоят.

    К слову сказать, в D2009 тоже появились дженерики. Но они местами глючные (сам экспериментировал) и значительно менее функциональны, чем на C#.
    Дельфи вообще в последних версиях дерет кое что из .NET технологий, но получается это несколько куцо - прежде всего, по причине отсутствия общей системы классов и несколько архаичной VCL библиотеки с кучей пережитков.

    А вот Delphi.NET - вообще IMHO бред. Проще уж сразу на C#

    Дельфи просто все как-то пролетает мимо кассы в последнее время в своей целевой нише. Системщики как сидели так будут сидеть на С++, а прикладники и интерфейсники переходят на С# и WEB технологии.
    Круг задач, где Дельфи с своей архаичной VCL будет оптимальным выбором стремительно сужается (если не брать поддержку старых проектов).
    ОтветитьУдалить
  55. АнонимныйMay 26, 2010 12:36 PM
    Хороший ответ))

    Из Ваших убедительных слов видно что на текущий момент времени 'VС++' + C# явно обгоняют Delphi или Delphi где-то стоит между ними, смотря с какой стороны смотреть)).
    Ну а как Вы думайте что будет лет так через 5-7?, с теме же тенденциями развития?

    Я думаю что для Delphi эбакадеро
    A) "cдерет" что есть нужное у C#
    Б) Станет РЕАЛЬНО кроссплатформенной (без "скриптовой" начинки)
    ОтветитьУдалить
  56. АнонимныйMay 26, 2010 02:26 PM
    >Из Ваших убедительных слов видно
    >что на текущий момент времени 'VС++' + C# явно обгоняют Delphi
    >или Delphi где-то стоит между ними,
    >смотря с какой стороны смотреть)).
    Не совсем...
    Это скорее раньше Delphi стоял где-то ровно посередине между С++ и VB (при этом почти полностью перекрывая VB, за исключением простоты)
    Дельфи был достаточно быстр в рамках своих задач, позволял просто и удобно писать компоненты в рамках среды, и при этом вполне универсален, А ГЛАВНОЕ позволял все это делать в кратчайшие сроки.

    Сейчас, к сожалению, он по всем этим фронтам перекрыт новейшим творением от MS.
    В MS, надо признать, всегда были хорошие маркетологи и они всегда очень четко знают у кого и что содрать и куда и как нужно нанести следующий удар.

    >Ну а как Вы думайте что будет лет так через >5-7?, с теме же тенденциями развития?
    >Я думаю что для Delphi эбакадеро
    >A) "cдерет" что есть нужное у C#
    Может быть...
    Но есть в этом одна проблема.
    VCL - реально устарел. Он становится менее удобен, и менее логичен (в сравнении, конечно).
    Бесконечные вариации имен функций + не вполне логичное их расположение (типа так уж исторически сложилось).

    Или, например, все эти TDataSet+TDataSource и как следствие целый набор дополнительных DataAware компонент. В .NET это решено уже более элегантно, через куда более универсальный Binding.

    К тому же сам Паскаль со своей строгостью уже не так актуален и удобен и в мелочах и в более крупных вопросах.
    Например, такие понятия в .NET как namespace в в рамках множества файлов все же удобнее, чем разбиение на unit-ы, которое приводит подчас к борьбе с "circular reference" в больших проектах с множеством хитро переплетенных классов.
    Да и лежащая под этим паскалевская необходимость объявления всего сверху вниз лишь мешает.

    Так же общая система классов с Жабе и C# все же более предпочтительнее для прикладного программирования, чем простые, но тупые классические типы.
    Да еще много чего...

    Если же все это и многое другое Дельфи преодалеет - то это может и будет круто.
    Но, боюсь, тогда это будет уже не Дельфи и уже не совсем раscal.
    А что тогда?
    Для примерного ответа взгляните на Delphi.NET.
    Не уверен, что вам это понравится.
    Хотя...

    Б) Станет РЕАЛЬНО кроссплатформенной (без "скриптовой" начинки)
    Здесь уже говорилось, что, например, MacOS X это не очень-то перспективная платформа для офисных Дельфей. Я не верю, что дельфи программисты начнут рисовать интерфейс из рюшечек, как это надо для любителей MacOS.

    Короче, я не разделяю вашего оптимизма по поводу будущего Дельфей, и не думаю, что у относительно небогатой Embarcadero хватит сил тягаться с MS на одном поле, если они будут в роли догоняльщика (как сейчас).

    Скорее всего, Дельфи займут очень узкую нишу.
    Да и специалистов через 5-7 лет найти будет крайне тяжело.

    Ну да время покажет...
    В любом случае, понаблюдать будет интересно.
    ОтветитьУдалить
  57. АнонимныйMay 27, 2010 08:45 AM
    >Для примерного ответа взгляните на Delphi.NET.

    Помоему он официально умер.

    >Короче, я не разделяю вашего оптимизма по поводу будущего Дельфей, и не думаю, что у относительно небогатой Embarcadero хватит сил тягаться с MS на одном поле, если они будут в роли догоняльщика (как сейчас).

    У Борлонда в 1995-2002, хватило же сил тягаться. Стратегия простая, посто "воруй" плюсы и всё, чем они частично и занимаются.

    >Я не верю, что дельфи программисты начнут рисовать интерфейс из рюшечек, как это надо для любителей MacOS.

    Я имел виду что. Если перекомпиляция с WIN на MAC и Lin займёт мало времени(и код не нужно будет менять), то на рюшечеки можно положить. Грех этим не пользоваться... (При этом надо помнить что WIN платный а с пиратками начинают бороться активнее,. альтернатива должна быть)

    >Скорее всего, Дельфи займут очень узкую нишу.
    Да и специалистов через 5-7 лет найти будет крайне тяжело.

    Не разделяю вашего пессимизма)



    Интересно, что Вы думайте о MONO ?
    ОтветитьУдалить
  58. >Я не верю, что дельфи программисты начнут рисовать интерфейс из рюшечек, как это надо для любителей MacOS.
    На делфи под виндой рюшечки рисуются достаточно просто. И не вижу никакой проблемы рисовать рюшечки под маком
    ОтветитьУдалить
  59. АнонимныйMay 28, 2010 12:53 AM
    > У Борлонда в 1995-2002, хватило же сил тягаться.
    > Стратегия простая, посто "воруй" плюсы и всё, чем они частично и занимаются.
    Не знаю у кого там воровал Борланд, но первые версии Дельфей были реально прогрессивнее, чем у конкурентов.
    Видимо, у них тогда были свои мозги и идеи.

    >Я имел виду что. Если перекомпиляция с WIN на MAC и Lin займёт мало времени
    >(и код не нужно будет менять), то на рюшечеки можно положить.
    >Грех этим не пользоваться... (При этом надо помнить что WIN платный
    >а с пиратками начинают бороться активнее,. альтернатива должна быть)
    Подумайте, что вы говорите. Если с пиратками начинают бороться, то MacOS тут уж точно не поможет.
    При такой высокой цене на Apple ни какие организации не будут их закупать в качестве офисных компьютеров.
    Они как были домашними и дизайнерско-музыкантскими так такими и остаются.
    Посмотрите на рынок программного обеспечения для MacOS.
    Что вы на Delphi можете предложить на этом рынке?

    Остается только Linux.
    Может быть..., но уже был Kylix и благополучно умер. Причина оказалась все та же - очень маленький спрос.
    А ведь это было на подъеме Linux-мании.

    >>Скорее всего, Дельфи займут очень узкую нишу.
    >>Да и специалистов через 5-7 лет найти будет крайне тяжело.
    >Не разделяю вашего пессимизма)
    Так уже тяжело. Молодежь в основном ориентируется на более новые технологии.

    >Интересно, что Вы думайте о MONO ?
    Думаю, что пока сама MS не захочет выпускать FrameWork-и для определенных платформ, лучще не связываться с такими поделками как MONO.

    А вообще, пишите на Delphi пока считаете это для себя наиболее эффективным.
    ОтветитьУдалить
  60. АнонимныйMay 28, 2010 01:20 AM
    >Подумайте, что вы говорите. Если с пиратками начинают бороться...

    -альтернатива должна быть - Я имел виду MacOS
    -пиратками начинают бороться - Я имел виду бесплатный Linux

    >Может быть..., но уже был Kylix и благополучно умер. Причина оказалась все та же - очень маленький спрос.

    На сколько мене известно Kylix был на QT которая в то время была платная, и получалось Борланд здесь облажался, т.к. такое решение никому ненужно. Сейчас же ситуация изменилась, насколько мне известно QT сменил тип лицензии, и стал бесплатным.

    >Думаю, что пока сама MS не захочет

    Уверен что она никогда не захочет ))
    ОтветитьУдалить
  61. АнонимныйMay 28, 2010 07:45 AM
    > -альтернатива должна быть - Я имел виду MacOS
    Всегда хорошо иметь альтернативу. Кто против-то?
    Я лишь усомнился в связке MacOS+Delphi.
    Вам же это теоретически нужно, чтобы например быстро перевести приложение на MacOS.
    Вопрос звучит собственно - А кому-нибудь нужно там ваше приложение?
    Или вы собрались очередной красивый графический пакет на Дельфях писать?
    Не знаю, но по моим прогнозам рынок Дельфевых приложений будет очень и очень скуден на Apple.
    Тем более, что Дельфи стоит приличных денег, а Apple снабжает разработчиков "бесплатными" средствами типа Xcode.

    >-пиратками начинают бороться -
    >Я имел виду бесплатный Linux
    Но в 99% офисах его пока как не было так и нет...
    ОтветитьУдалить
  62. АнонимныйMay 28, 2010 08:11 AM
    >А кому-нибудь нужно там ваше приложение?

    Ну это наверно вопрос к больше к маркетингу, чем к возможностям сред разработки.
    Например я пользуюсь программой для удалённого подключения TeamViewer, она удобна и проста, не требует инсталляции, ей не нужен .net и перед запуском накатить на Win какие нибудь обновления. Она просто тупо работает(я её не рекламирую, моё мнение). И когда я через неё управлял Macoм удалённо c Win я испытал восторг. Я считаю это качественное ПО. Нужно ли оно там? Незнаю, Мне нужно.
    ОтветитьУдалить
  63. АнонимныйMay 28, 2010 08:47 AM
    > Ну это наверно вопрос к больше к маркетингу,
    > чем к возможностям сред разработки.

    Ну что ж, будет интересно посмотреть, чем пополнится MacOS с появлением там Дельфи.
    Если это вообще произойдет, конечно...
    ОтветитьУдалить
  64. АнонимныйJun 1, 2010 09:37 AM
    По поводу 64-битный компилятора, мне понравился пост Дмитрия, полностью с ним согласен

    Dmitry Kuzmenko
    15.6.09
    Кросс-платформенность круче, чем 64-разрядность
    В оригинале, конечно, фраза Уэйна Вильямса (директора Embarcadero) звучит несколько иначе
    "cross-platform is now a higher priority than a 64-bit compiler, though both are planned, and that we will see the first cross-platform release next year."

    Но смысл примерно тот же. Когда я увидел, что якобы в массе разработчики, использующие Delphi, алчут поддержки компиляции 64-разрядных приложений, мне вспомнилась фраза Джокера:
    "я как собака, пытающаяся укусить проезжающий автомобиль - если я его поймаю, что я с ним буду делать?"
    Извиняюсь за подобные аналогии, но на мой (бизнес-) взгляд рынок 64-разрядных приложений (создаваемых на Delphi) практически равен нулю. То есть, конечно, есть разработчики, желающие компилировать под 64-разряда, получая все преимущества, и есть клиенты, желающие использовать такие приложения. Но разработчиков по сравнению с клиентами очень мало, а разработчиков, желающих 64-разрядности, совсем мизер. Грубо говоря, один процент от тысячной доли процента.

    Поэтому на 64-bit Delphi, как на бизнес-идею, я пока смотрю с подозрением. "На вырост" это может быть хорошим заделом, но когда этот вырост произойдет...

    С другой стороны, в отношении 64-bit Delphi также была заявлена (?) возможность распараллеливания кода по ядрам многоядерных процентов, что на мой взгляд в данный момент более важно, чем 64-разрядность как таковая.

    Впрочем, совсем об отмене 64-bit Delphi речи не идет, просто приоритеты чуть поменялись, и в очень правильную сторону. Все-таки страдающих по Kylix и бросившихся в .Net в сумме больше, чем желающих 64-разрядности.
    ОтветитьУдалить
  65. > Поэтому на 64-bit Delphi, как на бизнес-идею, я пока смотрю с подозрением.
    > "На вырост" это может быть хорошим заделом, но когда этот вырост произойдет...

    Embarcadero правильно делает, что смотрит в сторону 64-bit.

    Это уже реальность, а не просто идея "на вырост". Объясню почему:
    Количество компьютеров как стационарных так и ноутов с 64-битной системой растет.
    Конечно же, далеко не всем пользователям для работы так уж нужна память более 3 гигов, за исключением тех, кто профессионально работает с обработкой видео и/или графики.
    Но вот количество серверов, на которых 64-bit и памяти больше 4 гигов растет еще быстрее. И это вполне оправдано.

    Кто-нибудь может сказать, что x86 приложения итак хорошо выполняются на 64-битных платформах.
    Так то оно так, но во-первых, нельзя забывать, что потеря хоть и небольшая производительности все же есть за счет WOW64
    Во-вторых, сопряжение 32-битных приложений с 64-битными библиотеками и приложениями может нести с собой определенный и местами вполне серьезный гемор.
    В-третьих - отсутствие 64-бит в связи с вышеперечисленным - это плохо с точки зрения маркетинга и планирования при организации нового проекта.

    Поэтому, даже если вам конкретно сейчас 64-бит не особо надо, то через пару лет, когда вы допишете свое творение, у большей половины уже эти 64-бит будут стоять по умолчанию...
    ОтветитьУдалить
  66. > Во-вторых, сопряжение 32-битных приложений с 64-битными библиотеками и приложениями может нести с собой определенный и местами вполне серьезный гемор.

    Часть разработчиков ушла с Delphi именно по этой причине. Только в данном случае ситуация обратная, разработчики на Delphi не могут создавать библиотеки работающие с 64-битными приложениями.

    Сама по себе 64-битность, нафиг не сдалась. Но иногда без её поддержки просто никак.
    ОтветитьУдалить
  67. > Часть разработчиков ушла с Delphi именно по этой причине.
    > Только в данном случае ситуация обратная, разработчики на Delphi
    > не могут создавать библиотеки работающие с 64-битными приложениями.

    > Сама по себе 64-битность, нафиг не сдалась.
    > Но иногда без её поддержки просто никак.

    Вот именно.

    Поэтому 64-бит для Дельфей могут оказаться даже более актуальными, чем абстрактые мечтания на тему:
    "Вот уже скоро будет версия для MacOS, тогда мы всем покажем!" :)
    ОтветитьУдалить
  68. АнонимныйJun 4, 2010 09:42 AM
    Ну пост от 15.6.09 почти год, всё меняется...

    Значит Embarcadero на правильном пути ))
    ОтветитьУдалить
  69. АнонимныйJun 8, 2010 03:12 AM
    >> плюс обязательное наличие дотнет.
    > IMHO: Это вообще уже "детско-садовский аргумент".
    > Неужели в 2010 году это кого-то может всерьез напугать, да еще и на Win платформе?
    Кхм... скажу по скромному опыту, найдётся 1000 и 1 причина почему FrameWork не будет работать\функционировать\устанавливаться\переустанавливаться на рабочей машине. Думаю ситуация исправится только тогда, когда он сам станент неотъемлемой частью ОСи.

    > А сам Дельфи вообще очень средненько оптимизирует в машинный код (иногда, на порядок хуже VС++)
    Информация не актуальна, суровые 90-е уже давно прошли. Кстати, давненько где-то натыкался на подобное исследование, сравнивался код генерируемый компиляторами Делфи и Cи++, так вот для некоторых ситуаций Cи++ генерировал совершенно невменяемое нечто (но думаю эта информация тоже устарела).

    > Да и лежащая под этим паскалевская необходимость объявления всего сверху вниз лишь мешает.
    Хэх, видимо вам в жизни никогда не приходилось разбираться в чужих проектах.
    Везунчик :D

    > При такой высокой цене на Apple ни какие организации не будут их закупать в качестве офисных компьютеров.
    Наглядный пример - корпорация Google, на текущий момент она полностью отказывается от ОСи Windows, как альтернативу планируют использовать MacOS X и Linux.

    > Извиняюсь за подобные аналогии, но на мой (бизнес-) взгляд рынок 64-разрядных приложений (создаваемых на Delphi) практически равен нулю.
    Да нет, вы учитываете десктопы и совершенно забываете про сервера.
    ОтветитьУдалить
  70. > Кхм... скажу по скромному опыту, найдётся 1000 и 1 причина почему FrameWork не будет
    > работать\функционировать\устанавливаться\переустанавливаться на рабочей машине.
    1000 и 1? ;) Не мало ли ;)
    А вообще, по личному скромному опыту всегда найдется куча причин, по которым что-нибудь, где-нибудь не заработает как надо.
    И на FrameWork здесь не стоит пенять.

    >Информация не актуальна, суровые 90-е уже давно прошли.
    Давайте не будем ссылаться на суровые 90-е.
    Проведем небольшой эксперимент - реализуем один и тот же алгоритм в двух средах.
    А именно посчитаем число Пи до 10000 знаков.
    Исходники можете взять здесь:
    http://rapidshare.com/files/396840357/Pi.rar.html
    У меня на Core2Duo 6750 при включенных оптимизациях получились следующие результаты:
    Delphi2010 ~ 6150ms; C#(VS2010) ~ 6790ms

    Итого Delphi обогнал C# ~ на 10%

    Много это или мало, каждый пусть решает для себя.
    По большому счету, это конечно же не разница, поскольку в стандартных офисных, БД и учетных приложениях скорость этим не мерится и 10% в вычислительных алгоритмах ничего не решает.
    ( К слову сказать, тоже самое на С++ выполняется ~ 5400ms )

    > Хэх, видимо вам в жизни никогда не приходилось разбираться в чужих проектах.
    >Везунчик :D

    Приходилось довольно часто. А поэтому даже и постоянное прыгание между interface и implementation задалбывало.
    ОтветитьУдалить
  71. > Да нет, вы учитываете десктопы и совершенно забываете про сервера.
    + много.

    > Наглядный пример - корпорация Google
    Пару лет назад Google зарабатывал столько, что не успевали придумать куда вложить всё заработанное. Пруфлинк.=)

    > А вообще, по личному скромному опыту всегда найдется куча причин, по которым что-нибудь, где-нибудь не заработает как надо.
    И чем больше в цепи звеньев, тем выше шансы того, что это случится, и тем сложнее будет вычислить причину.

    > Приходилось довольно часто. А поэтому даже и постоянное прыгание между interface и implementation задалбывало.
    А я вот так и не могу толком привыкнуть к чтению C# исходников. В этом плане Delphi для меня удобнее. Сначала изучил только интерфейсную часть, потом, если надо и реализацию. Впрочем, я не использовал Сворачивание блоков кода и диаграммы.
    ОтветитьУдалить
  72. АнонимныйJun 9, 2010 04:21 AM
    а мне вот приходиться привыкать к Delphi-коду, в конторе тьма наработок в .pas - я вешаюсь!
    одно чего стоит, для for переменную-итератор отдельно объявлять. Еще конструкции Ovject:=Type.Create; - парюсь постоянно.
    А в принципе язык хороший.
    А вот RAD Studio - просто калл, а не IDE!
    ОтветитьУдалить
  73. АнонимныйJun 11, 2010 02:59 AM
    COBOL, FORTRAN, ADA, PL/1 тоже еще кто-то, где-то использует. И даже обновленные версии компиляторов иногда выходят.
    Теперь в этом ряду и DELPHI

    Ключевой вопрос: Вы что, хотите быть специалистами по древним языкам?
    Ну тогда Delphi - это безусловно ваш выбор.

    Подумайте только, кому и где вы будете нужны завтра?

    Сегодня в мире Windows все крутится вокруг .NET технологий, завтра тоже. Послезавтра, возможно, будет что-то новое.
    Но вокруг Delphi уже точно ничего особенного крутится не будет.

    Люди уже оперируют такими вещами как LINQ и Entity Framework, пользуются регулярными выражениями, не первый год компилируют под девайсы и прочее и прочее,
    а дельфийцы в это время все гадают будет у них в следующей версии 64-бит или еще на годик отложат...
    :D

    "Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда–то попасть, надо бежать как минимум вдвое быстрее!" (Алиса в Зазеркалье)
    ОтветитьУдалить
  74. > а дельфийцы в это время все гадают будет у них в следующей версии 64-бит или еще на годик отложат...
    Очень остроумно подмечено. Уже 3й или 4й год гадаем. =)

    > Ключевой вопрос: Вы что, хотите быть специалистами по древним языкам?
    Хороший программист - он на то и программист, чтобы уметь программировать без привязки к конкретному языку. Имхо, главное - следить за тенденциями.

    Как не раз писали западные блоггеры, если нанять хорошего Delphi-программиста для программирования под .NET то он выучит C# за пару месяцев. А если нанять .NET-чика и посадить его на Delphi - он не захочет учиться вообще.
    ОтветитьУдалить
  75. АнонимныйJun 11, 2010 03:30 AM
    #Как не раз писали западные блоггеры, если нанять хорошего Delphi-программиста для программирования
    #под .NET то он выучит C# за пару месяцев. А если нанять .NET-чика и посадить его на Delphi
    # - он не захочет учиться вообще.

    Что вполне естественно со стороны .NET-чика, поскольку нафига ему вообще учить эти дельфевые рудименты.

    Википедия: РУДИМЕНТ, -а, муж.
    1. Недоразвитый, остаточный орган, бывший полноценным на предшествующих стадиях существования организма (спец.).
    :)
    ОтветитьУдалить
  76. АнонимныйJun 11, 2010 01:51 PM
    >> Как не раз писали западные блоггеры, если нанять хорошего Delphi-программиста для программирования под .NET то он выучит C# за пару месяцев. А если нанять .NET-чика и посадить его на Delphi - он не захочет учиться вообще.

    > Что вполне естественно со стороны .NET-чика, поскольку нафига ему вообще учить эти дельфевые рудименты.

    Такой .NET-программист в недалёком будущем сам станет РУДИМЕНТОМ (Недоразвитый, остаточный орган, бывший полноценным на предшествующих стадиях существования организма) ;-)
    ОтветитьУдалить
  77. АнонимныйJun 11, 2010 03:09 PM
    #Такой .NET-программист в недалёком будущем сам станет РУДИМЕНТОМ
    Безусловно станет. Это необратимо.
    Количественное, как всегда, перерастет в качественное. Появятся новые технологии на новом уровне и новом витке развития.
    И .NET станет историей.

    А пока историей становится Delphi.

    Только если кто-то по лени, по наивности или по привычке цепляется за старое, то это не есть хорошо и не от большого ума. И это уж точно не прагматично и не практично.
    ОтветитьУдалить
  78. > если кто-то по лени, по наивности или по привычке цепляется за старое, то это не есть хорошо и не от большого ума
    Есть ещё такая вещь как опыт и наличие работы. Зачем менять хорошую работу на Delphi на фиг знает какую на .Net? :) Особенно, если работа действительно хорошая. ;)
    ОтветитьУдалить
  79. АнонимныйJun 13, 2010 03:02 AM
    >Сегодня в мире Windows все крутится вокруг .NET технологий, завтра тоже. Послезавтра, возможно, будет что-то новое.

    По мимо мира Windows, есть и другие миры. Апел по баблу догнал и обогнала MS 222 Млд против 220. В мире Windows не всё крутится вокруг .NET, далеко не всё. И завтра и послезавтра там всё не будет.



    >Люди уже оперируют такими вещами как LINQ и Entity Framework, пользуются регулярными выражениями, не первый год компилируют под девайсы и прочее и прочее,..

    LINQ и Entity Framework оперирую как понятиями, у Вас есть примеры кто это использует?
    Регулярными выражения для Дел. были написаны по-моему когда ещё дот нета не существовало, или Вас беспокоит что Борланд не включил их в стандар. поставку?


    >Что вполне естественно со стороны .NET-чика, поскольку нафига ему вообще учить эти дельфевые рудименты.

    Ну судя по перечислимым выше плюсам .NET, Delphi не так и сильно отстал, чтоб его называть рудиментом.


    >#Такой .NET-программист в недалёком будущем сам станет РУДИМЕНТОМ
    Безусловно станет. Это необратимо.
    Количественное, как всегда, перерастет в качественное. Появятся новые технологии на новом уровне и новом витке развития.
    И .NET станет историей.

    Честно говоря, я не понимаю о каких витках развития Вы несёте, (или по вашему переделать из компилятора в транслятор, написать службу по сборке неиспользуемой памяти это виток развития) но, по моему мнению всё интересное придумано до 2003, сейчас это только улучшается. Тот же Windows 95->XP ощутимые изменения, XP->7 почти тоже самое с более красивым интерфейсом. тоже самое и с офисом, да и с другим ПО.

    Интересно по вашим доводом, RUBY можно назвать витком развития?
    ОтветитьУдалить
  80. > По мимо мира Windows, есть и другие миры.
    > Апел по баблу догнал и обогнала MS 222 Млд против 220.
    > В мире Windows не всё крутится вокруг .NET, далеко не всё.
    > И завтра и послезавтра там всё не будет.

    А при чем здесь Apple?
    Или вы тоже надеятесь, что выход Delphi для Apple что-то изменит в раскладе Delphi vs .NET? ;)

    > LINQ и Entity Framework оперирую как понятиями, у Вас есть примеры кто это использует?
    Ну не знаю...
    Я вот LINQ использую частенько, поскольку это упрощает код и уменьшает количество лишней писанины.
    Например, написать в коде что-то типа:
    List emp = new List();
    ...
    var qry = from e in emp
    where e.Salary > 70000
    orderby e.Name
    select e.Name;

    foreach( var q in qry )
    ...
    Где Employers - это ни какой не датасет, а просто класс, хранящий данные о работнике.

    Это гораздо проще, быстрее и читаемее, чем реализация, например, очередного наследника от TObjectList-а с дальнейшей реализацией цикла поиска с записью в другой список и последующей сортировки.

    > Ну судя по перечислимым выше плюсам .NET,
    > Delphi не так и сильно отстал, чтоб его называть рудиментом.
    Не знаю, можно ли назвать Дельфи рудиментом, но то что он ощутимо отстал в идеологическом плане - это IMHO факт.
    А вообще, выше уже написали, что и FORTRAN еще где-то используется. Значит, где-то и Дельфи пристроят.
    ОтветитьУдалить
  81. В верхнем листинге не прошли знаки больше меньше в объявлении дженерик листа. Очевидно были проглочены, как тэги.
    Поэтому, заменю их на обычные скобки
    List(Employers) emp = new List(Employers)();
    ОтветитьУдалить
  82. АнонимныйJun 16, 2010 05:11 AM
    >А при чем здесь Apple?
    Или вы тоже надеятесь, что выход Delphi для Apple что-то изменит в раскладе Delphi vs .NET? ;)

    Возможно что да.

    >Я вот LINQ использую частенько, поскольку это упрощает код и уменьшает количество лишней писанины. ...

    LINQ - Класная вещь, Интересно она только под MS SQL Serv, или на других СУБД тоже работает?
    ОтветитьУдалить
  83. АнонимныйJun 16, 2010 08:07 AM
    >> А при чем здесь Apple?
    Или вы тоже надеятесь, что выход Delphi для Apple что-то изменит в раскладе Delphi vs .NET? ;)

    > Возможно что да.

    Не исключено, ниша пока не занята.
    ОтветитьУдалить
  84. > LINQ - Класная вещь, Интересно она только под MS SQL Serv, или на других СУБД тоже работает?
    LINQ вообще не завязан на БД. Теоретически он должен уметь работать с массивами, списками, XML и любыми Базами Данных. Но практически я с ним не работел, поэтому реального положения дел не знаю.
    ОтветитьУдалить
  85. > LINQ - Класная вещь, Интересно она только под MS SQL Serv,
    > или на других СУБД тоже работает?
    LINQ, как уже написал Aleksey Timohin, не предназначен только для БД.
    В этом-то собственно и есть его удобства.
    Собственно для БД есть "LINQ to ADO.NET" и "LINQ to SQL".
    А, например, "LINQ to Object" позволяет делать запросы к спискам и коллекциям, сильно помогая в работе с ними. Простенький пример я уже привел выше.
    Общий смысл в этом - унифицировать и упростить выборку и манипуляцию с данными из разнородных источников.

    > Не исключено, ниша пока не занята.
    Может быть. Хотя, лично я сильно сомневаюсь, но может быть...
    ОтветитьУдалить
  86. АнонимныйJun 17, 2010 01:36 AM
    >А, например, "LINQ to Object" позволяет делать запросы к спискам и коллекциям, сильно помогая в работе с ними. Простенький пример я уже привел выше.

    Спасибо за ответ, Эта тема мне что-то напомнила QCL (в BOLD/ECO), только там можно было работать только с собственными объектами.

    Хорошо бы, было бы, если Ембакадеро "слижет" LINQ )
    ОтветитьУдалить
  87. АнонимныйJun 24, 2010 01:11 AM
    Это сейчас Microsft рекомендует и продвигает свой язык C#. Сейчас вот читаю статью -
    "Microsoft разрабатывает новый язык программирования Axum"
    Поклонимся им. Скоро C# устареет и MS будет рекомендовать переходить на Axum. Для них это бизнес.

    Подумайте об истории всевозможных стратегий доступа к данным, разработанным Microsoft. ODBC, RDO, DAO, ADO, OLEDB, теперь вот ADO.NET - И все абсолютно новые! Может это было вызвано технологической необходимостью? Может это результат некомпетентной группы проектирования, которой необходимо придумывать по-новой доступ к данным каждый чертов год? (Возможно, это в самом деле так.) Но конечный результат - всего лишь огонь для прикрытия. Конкуренты не имеют никакого другого выбора, кроме как тратить своё время, переписывая код под новые библиотеки и поспевая за лидером - время, которое они не могут использовать для создания новых возможностей.
    Почитайте вот эту статью.
    http://russian.joelonsoftware.com/Articles/FireAndMotion.html
    ОтветитьУдалить
  88. АнонимныйJun 24, 2010 01:14 AM
    Менее успешные компании - это те, кто тратит слишком много времени ловя каждое движение Microsoft, гадая в каком направлении она пойдёт дальше. Люди начинают волноваться по поводу .NET и решают полностью переделать архитектуру под .NET, потому что они думают, что они вынуждены это сделать. Microsoft ведёт по вам огонь, и это всего лишь огонь прикрытия для того чтобы они могли двигаться вперёд, а вы нет. Таковы правила игры, дружок
    ОтветитьУдалить
  89. АнонимныйJun 29, 2010 03:29 AM
    Джоеля почитать иногда познавательно. Он мужик весьма умный. Да только...

    > ... ODBC, RDO, DAO, ADO, OLEDB, теперь вот ADO.NET - И все абсолютно новые!
    ODBC - весьма полезная вещь и стандарт де факто, но примитивен и сложен, а RDO - более простая оболочка для нее же
    OLEDB - по сути основанный на COM приемник ODBC, а ADO более удобный способ ощения с ним.
    ADO.NET - новое поколение ADO под .NET
    И почти все эти технологии вполне успешно применялись и применяются до сих пор.

    Чего нельзя сказать о BDE от Borland. Который на этом фоне был практически мертворожденным. Его конечно тоже использовали кое где по началу, но почти все достаточно быстро отказывались в пользу найтивных решений или решений от MS.

    А если более обще рассуждать вслед за Джоелем, то тогда тем более не стоит связываться с такими платформами как Дельфи. Поскольку Дельфи-то и вынуждены плестись в хвосте и отстреливаться из последних сил, т.к. практически на 100% зависят от того куда двинется MS.
    Это уже давно поняли в Borland-e и продали эту обузу, потом CodeGear облажалась, теперь дельфиты зависят от Embarcadero, пока ей не надоест нести убытки от поддержки Дельфей.

    А самое смешное, что у нас как раз Дельфи очень любят (особенно старые перд...), но практически никто ее не покупает (типа очень дорого) ;)
    ОтветитьУдалить
  90. АнонимныйJul 1, 2010 03:00 AM
    > Чего нельзя сказать о BDE от Borland. Который на этом фоне был практически мертворожденным. Его конечно тоже использовали кое где по началу, но почти все достаточно быстро отказывались в пользу найтивных решений или решений от MS.

    Вот тут вы неправы, в нашей конторе до сих по используют BDE для MS SQL, при всём его неудобстве и моральной старости по сравнению с ADO и DBX+CDS, он и по скорости {гдето в 2 раза} и по использ. памяти обгоняет. (из за этого аргумента попытка перейти на ADO провалилась, кончилось тем что написали свой инсталлятор для BDE)

    >А самое смешное, что у нас как раз Дельфи очень любят (особенно старые перд...), но практически никто ее не покупает (типа очень дорого) ;)

    Это вы точно подметили, хочу отметить что молодые перд... , тоже))
    ОтветитьУдалить
  91. АнонимныйJul 1, 2010 10:06 AM
    Из russian.joelonsoftware.com в тему про зависимости ))

    ... Другой лагерь назван мною лагерем журнала MSDN: по имени журнала для разработчиков, полного увлекательных статей обо всех способах отстрела собственной ноги при помощи продуктов Microsoft и собственного программного обеспечения. Лагерь журнала MSDN всегда пытается убедить вас применять новые и сложные внешние технологии, такие как COM+, MSMQ, MSDE, Microsoft Office, Internet Explorer и его компоненты, MSXML, DirectX (пожалуйста, самую последнюю версию), Windows Media Player и Sharepoint... Sharepoint! У кого он есть? Пышный наряд внешних зависимостей, каждая станет причиной сильнейшей головной боли, когда вы отправите ваше приложение заплатившему вам деньги клиенту, а оно откажется работать. Техническое имя этому – ад DLL. Это работает здесь: почему оно не работает там?

    Лагерь Реймонда Чена полагает, что разработчикам будет проще, если создать условия, когда однажды написанный код запускается везде (хорошо, на любой Windows платформе). Лагерь журнала MSDN полагает, что разработчикам будет проще, если им дать мощные куски кода, которые можно использовать для достижения собственных целей, если они хотят заплатить за это головной болью от невероятно сложной установки, про огромную кривую обучения даже не упоминаю. Лагерь Реймонда Чена за консолидацию. Пожалуйста, не делайте хуже, пусть то, что уже создано, продолжает работать. Лагерю журнала MSDN нужна раскрутка новых гигантских кусков технологии, с которыми никто не сможет справиться. ...
    ОтветитьУдалить
  92. >> А по моему Delphi скоро умрет. Никто здравомыслящий на Delphi не переходит. А те кто остался, рано или поздно переходят с нее на более продвинутые средства разработки приложений.

    Почему он должен умирать, если им активно пользуются?

    >> Перешел на Visual Studio. C# куда удобнее язык чем Object Pascal.

    Ну вот, ряды как грицо рядеют :(
    ОтветитьУдалить
  93. >> Ну или тот же фотошоп, на C#. :)
    Ну или вот Виста, один большой тормоз
    ОтветитьУдалить
  94. АнонимныйJul 2, 2010 01:29 AM
    > Лагерь Реймонда Чена полагает, что разработчикам будет проще, если создать условия,
    > когда однажды написанный код запускается везде (хорошо, на любой Windows платформе).

    А разве нет?

    > Лагерь журнала MSDN полагает, что разработчикам будет проще,
    > если им дать мощные куски кода, которые можно использовать для достижения собственных целей,

    А разве нет?

    Много контор могут похвастаться, что делают все с нуля и сами?
    Нет, очень и очень не много.

    Сто раз уже говорили, что Дельфи тем и был хорош, что позволял не особо копаясь в деталях, сконцентрироваться на конкретной задаче.
    Проблема в том, что в Дельфях я лично уже начинаю тратить гораздо больше времени для решения конкретной задачи, чем для решения того же самого и с тем же результатом в .NET.

    Осознав это, мы отказались от Дельфей.
    А-то что Дельфи при этом дает ~ 15% прироста скорости - для бизнес-задач наплевать и растереть.
    Гораздо важнее в какой срок я управлюсь.
    Вот и все, собственно.
    И это при том, что на Дельфях я отпахал лет так десять и писал и свои компоненты и датасеты и пр.

    > если они хотят заплатить за это головной болью от невероятно сложной установки,

    IMHO бред. Писали уже.
    Кому-то сложно поставить .NET? ;)
    Или это сложнее, чем установка Жаба-машины?

    > про огромную кривую обучения даже не упоминаю.

    Вообще бред.
    Если вы выбрали IT специальность, то вам всю жизнь придется учиться. Не можете - выберите себе что-нибудь попроще. Табуреты колотить, например.

    > Пожалуйста, не делайте хуже, пусть то, что уже создано, продолжает работать...

    Это звучит как "сделайте нам качественную автовазовскую классику. Не надо нам никакого вашего новомодного автопрома с современными движками, коробками, ABS, EBD, подушками, и пр и пр. Мы в нашем "Шараже-монтаже" уже знаем все винтики в наших "ведрах" и умело их подкручиваем, а учится не хотим, да и поздно нам."
    Ну что же, это тоже подход ;)
    ОтветитьУдалить
  95. АнонимныйJul 2, 2010 01:29 AM
    > Лагерь Реймонда Чена полагает, что разработчикам будет проще, если создать условия,
    > когда однажды написанный код запускается везде (хорошо, на любой Windows платформе).

    А разве нет?

    > Лагерь журнала MSDN полагает, что разработчикам будет проще,
    > если им дать мощные куски кода, которые можно использовать для достижения собственных целей,

    А разве нет?

    Много контор могут похвастаться, что делают все с нуля и сами?
    Нет, очень и очень не много.

    Сто раз уже говорили, что Дельфи тем и был хорош, что позволял не особо копаясь в деталях, сконцентрироваться на конкретной задаче.
    Проблема в том, что в Дельфях я лично уже начинаю тратить гораздо больше времени для решения конкретной задачи, чем для решения того же самого и с тем же результатом в .NET.

    Осознав это, мы отказались от Дельфей.
    А-то что Дельфи при этом дает ~ 15% прироста скорости - для бизнес-задач наплевать и растереть.
    Гораздо важнее в какой срок я управлюсь.
    Вот и все, собственно.
    И это при том, что на Дельфях я отпахал лет так десять и писал и свои компоненты и датасеты и пр.

    > если они хотят заплатить за это головной болью от невероятно сложной установки,

    IMHO бред. Писали уже.
    Кому-то сложно поставить .NET? ;)
    Или это сложнее, чем установка Жаба-машины?

    > про огромную кривую обучения даже не упоминаю.

    Вообще бред.
    Если вы выбрали IT специальность, то вам всю жизнь придется учиться. Не можете - выберите себе что-нибудь попроще. Табуреты колотить, например.

    > Пожалуйста, не делайте хуже, пусть то, что уже создано, продолжает работать...

    Это звучит как "сделайте нам качественную автовазовскую классику. Не надо нам никакого вашего новомодного автопрома с современными движками, коробками, ABS, EBD, подушками, и пр и пр. Мы в нашем "Шараже-монтаже" уже знаем все винтики в наших "ведрах" и умело их подкручиваем, а учится не хотим, да и поздно нам."
    Ну что же, это тоже подход ;)
    ОтветитьУдалить
  96. АнонимныйJul 2, 2010 01:39 AM
    >> Ну или тот же фотошоп, на C#. :)
    > Ну или вот Виста, один большой тормоз

    Не хотите тормозов вообще - пишите на чистом Си или C++.
    При чем здесь Дельфи?
    ОтветитьУдалить
  97. АнонимныйJul 2, 2010 01:47 AM
    > Вот тут вы неправы, в нашей конторе до сих по используют BDE для MS SQL, при всём его неудобстве и моральной старости по сравнению с ADO и DBX+CDS,
    > он и по скорости {гдето в 2 раза} и по использ. памяти обгоняет.
    > (из за этого аргумента попытка перейти на ADO провалилась, кончилось тем что написали свой инсталлятор для BDE)

    IMHO В вашем случае - это не лучший выход. ADO не очень шустрый - это точно.
    Поэтому, если вам нужна скорость и все современные технологии, лучше вам бы посмотреть в сторону OLEDB. Есть сторонние компоненты для Дельфей для чистого OLEDB.
    По скорости это будет сравнимо с вашим решением, а по удобству и перспективности скорее всего перекроет.
    ОтветитьУдалить
  98. АнонимныйJul 2, 2010 06:21 AM
    > Почему он должен умирать, если им активно пользуются?

    Потому что им активно уже никто не пользуется.
    Найти работу на Delphi в Штатах и в Европе стало крайне проблематично.

    В России им еще активно пользуются - это факт,
    но также активно и не платят за него.

    Delphi уже давно было пора перевести в open source. Тогда он еще пожил бы и без хозяина.
    ОтветитьУдалить
  99. АнонимныйJul 3, 2010 11:11 AM
    > Delphi уже давно было пора перевести в open source. Тогда он еще пожил бы и без хозяина.

    Что-то Лазарусу не очень живётся без хозяина, а вообще, мой давний эротический сон - Microsoft становится владельцем Delphi :D
    ОтветитьУдалить
  100. АнонимныйJul 4, 2010 03:42 AM
    > Что-то Лазарусу не очень живётся без хозяина, а во