|
0 Всего найдено: 26
tangueros
Сообщение
14/01/2012 22:04
Копия темы
Так умер Delphi или нет? (Для тех, кому лень читать – умер, умер. RIP, Delphi) Регулярные обсуждения на работе, да и в сети тоже (например здесь: ) сподвигли меня написать свой первый пост в блогах Фриланса. Итак, мое мнение таково: как мейнстрим Delphi умер и его применение новых (особенно больших и распределенных) проектах абсолютно неоправданно. По моему опыту практически весь промышленный код, который сейчас пишется на Delphi, это поддержка уже существующих давних проектов, заменять которые просто нецелесообразно (или не позволяют финансы). Классический пример – Диасофт. От него плюются все банки, в которых он установлен, но соскочить на него просто некуда (особенно удручающим выглядит положение для небольших контор, которые не могут себе позволить собственную разработку или купить что-то иное, да и выбор-то не богат для российского рынка, мягко скажем). А теперь по пунктам давайте сравним VCL и .Net. Это сравнение сделано по мотивам моей внутренней презентации, так что я не все сравнивал, а только актуальные для моей конкретной ситуации вещи. 1) нет нормальных event'ов с возможностью множества подписчиков – в .NET'e есть (+ учтите сложности с мнопоточностью – в 4.0 .Net их наконец-то решили, в Delphi за них и не брались) 2) xml и сериализация – в Delphi все руками, в .Net можно всем управлять декларативно через атрибуты + есть куча плюшек в виде linq2xml и синтаксический сахар для работы с xml через тип dynamic 3) параллельная и асинхронная работа – в Delphi все потоки создаются руками и все блокировки тоже делаются руками; в .Net'e – есть PLINQ + в новой версии 4.5 есть удобный синтаксис для асинхронной работы через async\await 4) сервисы: Delphi здесь щеголяет голым задом. Нет, формально поддержка сервисов типа есть, но при попытке импортировать Service Reference в проект для того, чтобы сгенерировать прокси у нас последняя версия Delphi тупо упала; при этом в .Net'e есть мощный конструктор в виде WCF, в котором из коробки и SOAP, и REST (не идеальный, конечно, но к примеру радует, что есть поддержка того же протокола OData) + возможность декларативно управлять всеми аспектами сервиса (т.е. один и тот же код легко работает с любым транспортом, любой системой авторизации и тп) плюс есть возможность управлять жизненным циклом сервиса, транзакциями, выдачей ошибок (а не только по старинке отправлять код ошибки или SOAP-овский отлуп), делать callback'и – в общем, много чего. 5) бизнес-процессы: в Delphi отсутствуют как понятие; нет, вполне вероятно какие-то сторонние компоненты есть для описания бизнес процессов, но по сравнению с WF все выглядит бледновато: - XAML и декларативное описание шагов workflow - designer'ы для desctop-приложений, а если руки прямые, то можно захостить и в вебе - tracing, logging и playback - интеграция с сервисами – можно сделать workflow видимым извне как сервис (и само собой есть интеграция и в обратном направлении – можно вызвать сервис как шаг бизнес-процесса) - продумана система отмены шагов (тут много тонкостей, скажем так – принципиальная возможность заложена и доработать не с нуля ее можно) 6) web: Зеро у Delphi. Только не надо говорить, что в студии разработки Delphi можно писать и на PHP – для этого есть куча других, более удобных инструментов. Что касается .Net, то здесь есть и ASP.NET WebForms, и ASP.NET MVC, и такой монстр как Sharepoint (это уже конечно вне .Net, но покажите мне что-нибудь подобное на Delphi). Правда, честно признаюсь сейчас ни одна из этих технологий не удовлетворяет моих потребностей (т.к. специфика задач требует реально хорошей горизонтальной масштабируемости, да все завязывать на стек Microsoft не всегда выгодно – здесь, как по мне, самое перспективное направление JS + HTML5 + REST) 7) aspects – аспектно-ориентированное программирование. Снова 0 на счету у Delphi, а у .Net есть атрибуты + инструменты типа Autofaq/Postsharp. Правда, скорее всего следующий пункт убьет бизнес-модель Postsharp'a, но не AOP в целом 8) templates & code generating – Пусто у Delphi, T4 у .Net. Да, он сложный и честно говоря недопиленный, но он есть! А кроме того, наверняка слышали (а если нет, то погуглите) об их проекте Roslyn – вот это реальная тема – позволить пользователям самим слегка допиливать язык, и при этом не говорить им типа "ну, все ребят – хотите добавить маааалеькую синтаксически-сахарную плюшечку в язык – открывайте книгу с красным драконом (Ахо, Ульман по компиляторам для тех, кто пока не в теме) и вперед – пишите свой компилятор поверх нашего". Именно эта фишка на корню убивает Postsharp 9) plugins и DI. Опять ничего у Delphi (непруха-то какая!). В .Net есть MEF, PRISM, Spring.Net (кто гуглит, тот обрящет) 10) linq – очень интересная тема. Считаю это был один из самых удачных проектов MS (и нет – я не фанат MS, мне конкретно не нравятся другие вещи в .Net'e и вообще в их стратегии, но об этом не сейчас) 11) наконец-то спустя 20 лет и в MS дошли до Code Contracts. Делфи, аууу?! Как итог: Делфи существенно отстает от .Net и начиная с некоторого момента всегда будет отставать (этот час X был где-то в 2005, когда вышел .Net 2.0). Также он накладывает сильные ограничения на архитектуру: никакого веба, никакой горизонтальной масштабируемости, никаких NoSQL баз (или welcome – ручками все писать). Да я в курсе, что есть такие прекрасные приложения, как Skype, QIP и .... (тут я силюсь вспомнить еще что-нибудь, но в голове один Диасофт, а кто с ним работал, даже под пытками не назовет его хм... прекрасным). Так вот, эти замечательные приложения хорошо написаны и отлично работают, но только в скайпе знаете ли трудно вести учет сделок на бирже или к примеру в QIP'е организовать сервис по закачке котировок (да, фондовый рынок – моя любимая тема). Как-то так. Комменты – welcome.
czech
Сообщение
14/01/2012 23:18
Копия темы
не хочу даже спрашивать про мой любимый turbo pascal, не расстраивайте
tangueros
Сообщение
15/01/2012 00:17
Копия темы
Увы, теплый ламповый Turbo Pascal, с которого все начинали (и я тоже) давно канул в Лету. Радует, что по крайней мере никто не утверждает, что "он еще ого-го и может выстрелить, а все эти новомодные языки MS от лукавого".
axismax
Сообщение
15/01/2012 03:05
Копия темы
Дмитрий, мои аплодисменты! Отличная статья! Просто нет слов... Добавил вас в избранные.
Sylancer
Сообщение
15/01/2012 10:34
Копия темы
Если бы мне предложили на выбор C# или Delphi для разработки коммерческого софта для десктопа (типа shareware), я бы выбрал Delphi. Потому что возможностей Delphi для этой задачи хватает вполне, при этом пользователь не отягощается необходимостью скачивать и устанавливать различные версии фреймворка. У нас в проекте коммерческие компоненты Delphi используются для обеспечения UI, а основная бизнес-логика пишется на C/C++. Получается красиво и быстро, никаких проблем с развертыванием приложения на клиентах, поддерживается вся линейка Windows, начиная с XP. У дотнета много "плюшек", но на десктопе большинство из них не нужны. Поэтому не все так однозначно, как описал автор.
tangueros
Сообщение
15/01/2012 11:31
Копия темы
Скажем так, у Делфи есть некая ниша, вне которой ему объективно мало что может предложить. Для меня эта ниша выглядит так: - десктопное standalone приложение - желательно с красивым интерфейсом (это сильная сторона Делфи, но при этом никакого подобия AJAX – только руками, это впрочем слабая сторона и WinForms, и WPF) - если клиент/сервер, то сервер – скорее реляционный (иначе – руками), при этом один нюанс: если у вас СУБД Sql Server и вам не хватает возможностей T-SQL, то расширить его можно опять только .Net'ом (Delphi под .Net не подойдет из-за ограничений самого SQLServer'a) - скорее без взаимодействия с Офисом и другими COM-серверами (иначе – руками) - по поводу развертывания – не знаю, что именно тянет с собой Делфи, но в .Net'e – да, вам возможно придется скачать 50 Мб фреймворка (но здесь опять же два момента: 1) скорее всего он уже скачан системой обновлений 2) 50 Мб скачать сейчас не проблема), но ничего более. - без поддержки нетривиальных архитектурных решений (тут впрочем и у .Net далеко не гладко) – например, сделать что-то в духе event sourcing как по мне нереально (если интересно, почитайте здесь , что это и зачем это – что называется "передний край технологий") или вот к примеру, попробуйте на Делфи реализовать DSL (Domain-Specific Language), чтобы функциональные требования описывать не в документах, которые по определению мгновенно устаревают и не имеют никакой связи с кодом, а вот таким манером: let account : Account let pupkin : Client pupkin opens account pupkin tranfers 10<dollar> to account if account.Balance <> 10 failwith "Balance hasn't changed" это реальный пример кода на F#, который (упрощенно конечно же) описывает функциональный тест по зачислению средств на счет. При этом, что важно – с одной стороны это не просто текст, это компилируемый код, который можно автоматически запускать для проверки корректности работы программы, а с другой стороны – его в принципе может читать и главное писать аналитик и показывать бизнесу, мол, смотрите, ваши новые требования оказываются рушат вот такой вот тест – давайте разбираться". И что главное – имея такой код можно утверждать, что программа заслуживает доверия с минимумом ручного тестирования путем клика на все кнопки и комбобоксы (если у вас сложная предметная область, скажем телеком, финансы, медицина – то регрессионное тестирование превращается в ад без подобных тестов или ничего реально нельзя гарантировать, потому что исправили в одном месте, а сломаться может в другом: пример из моей личной практики – добавили возможность асинхронных задач – сломалось логирование, причем весьма необычным способом) Ну, а про unit тестирование вообще молчу: на Делфи есть, что-то в духе NUnit, xUnit для тестирования и Moq, Rhino для создания тестовых заглушек? А есть ли на Делфи возможность сделать нормальный continuous integration, чтобы не ручками все собирать на машине главного разработчика? В общем, на Делфи можно сделать многое, но не все и выйти за пределы обозначенной ниши довольно-таки трудно
Dangover
Сообщение
15/01/2012 11:34
Копия темы
Очень однобокий обзор. Прямо у Delphi сплошные минусы. Насколько я помню его уже хоронят лет десять, а он все не умрет и все тут. Для крупного проекта я бы Delphi/C++ Builder не использовал, но для большинства проектов здесь – это отличная IDE.
alex1153
Сообщение
15/01/2012 11:36
Копия темы
а я бы применил библиотеку Qt (C++) . Но согласен, что никак бы не стал применять C#
Dangover
Сообщение
15/01/2012 11:44
Копия темы
Зачем сплошные плюсы? Можно же сделать и объективный обзор. Как по мне для реального RAD'а небольших приложений без необходимости портирования под другие платформы Delphi/C++ Builder – идеальные решения.
tangueros
Сообщение
15/01/2012 11:46
Копия темы
Собственно вопрос был Delphi или .Net. По поводу Qt – интересная кросс-платформенная альтернатива Java, но только в плане интерфейса, а вот в Application Server'е вы как его будете применять?
tangueros
Сообщение
15/01/2012 11:47
Копия темы
так, собственно, что и утверждалось. а если что-то кроме "быстро наваять несколько красивых формочек", то что?
alex1153
Сообщение
15/01/2012 12:14
Копия темы
насколько я знаю про Java (а практически ничего) , то это интерпретируемый язык. Посему не вижу никакой связи. Везде, где можно выполнить экзешник, созданный при помощи Delphi, также точно можно выполнить и Qt-проект (сравниваю так для ОС Win , а про кроссплатформенность Qt не упоминаю :) ) что есть Application Server и зачем он – не в курсе. А также, как к нему относиться та же Дельфи
tangueros
Сообщение
15/01/2012 12:24
Копия темы
насколько я знаю про Java (а практически ничего) , то это интерпретируемый язык – без обид, вы знаете действительно мало. Почитайте про JIT здесь "Везде, где можно выполнить экзешник, созданный при помощи Delphi, также точно можно выполнить и Qt-проект" – но далеко не везде этот exe-шник можно получить – компилятор Delphi есть далеко не для всех платформ (например ARM?) Почему делать промежуточный язык выгодно можно почитать здесь Что такое Application Server и зачем он нужен – здесь
Sylancer
Сообщение
16/01/2012 17:27
Копия темы
Видите ли, Дмитрий. Есть то, что называют мэйнстримом, а есть другие сферы, более узкоспециализированные. И очень часто использовать технологии мэйнстрима в этих сферах неоправданно дорого или неэффективно. Как и наоборот. И здесь вопрос не только каких-то конкретных языковых, платформенных или инструментальных возможностей, но также и скорости разработки, удобства сопровождения, интеграции, совместимости и еще массы всего-всего. Любые проекты, какие ни посмотри – мультимедиа, электронная коммерция, базы данных, геймдев, встраиваемые устройства, безопасность, сетевые технологии – требуют сильно различающихся подходов в проектировании и выборе средств. Проблема здесь, как я не раз убеждался, в том, что человек, отдавший годы на становление, начинает цепляться за свои любимые языки и технологии и "пихать" их туда, где им вообще не место. В результате имеем либо жирных и неповоротливых монстров, либо проекты, чрезвычайно переусложненные и тяжелые в сопровождении. Большинство сравнений класса "C++ vs Java", "C# vs Delphi" и "PHP vs ASP.NET", как правило, однобоки, предвзяты и рассматриваются вне контекста предметной области, задачи которой эти языки призваны решать. И данная тема – не исключение. Да, какие-то языки устаревают и становятся уделом небольших групп или перекочевывают в узкоспециализированные области. Что, впрочем, не мешает специалистам в этих областях очень неплохо зарабатывать. Производство музыкальных инструментов со временем тоже сильно подешевело и поставлено на конвейер. При этом штучные поделия ценятся не меньше, а то и больше прежнего. Такая вот аналогия. Я пишу на C++ и регулярно слышу от сторонников других языков о переполнениях буфера, проблемах управления памятью и прочих ужасах, якобы присущих C++, причем сам с этими вещами почти никогда в практических условиях не сталкиваюсь. Аналогично, дотнетчики уже замучились парировать укоры в "бездушном" сборщике мусора, который "тормозит, когда ему вздумается". Ну а об неинтеллектуальном труде дельфистов уже давно ходят анекдоты. Но это все – клише, которые не следует принимать на веру. Не убедившись лично, по крайней мере. На такие темы давно пора наложить мораторий и начать уважать опыт/знания других, а еще лучше – обмениваться опытом и взаимообогащаться. Это полезнее и продуктивнее, во всех отношениях.
tangueros
Сообщение
16/01/2012 18:16
Копия темы
Проблема вот в чем. Я привел список из 11 пунктов, которые меня не устраивают в Делфи (его можно расширить) и в которых на мой взгляд он проигрывает .Net'у (и Java кстати тоже – вот в сравнении Java и .Net все намного интереснее и однозначного ответа там точно нет, по крайней мере для меня). Так вот, пока я не увидел аналогичного списка в пользу Делфи пусть даже в какой-то узкой области – в основном, общие фразы. Вот это была бы интересная дискуссия. Насчет клише: их-то я как раз старался избегать и писать только конкретику. "Бездушных" сборщиков мусора у меня нет. Кроме того, поскольку я сам пишу на Делфи (и начинал кстати с него по большому счету), я отдаю ему должное и обрисовал ту нишу, где у него есть сильные стороны. Дело в том, что это ниша стремительно сужается, т.к. а) на десктопе его вытесняют Java и .Net 2) многие переходят с десктопа в веб (к примеру в Windows 8 один из основных языков разработки приложений будет Javascript + html5) По поводу C++. Он занимает свою нишу, откуда .Net его вряд ли в обозримое время вытеснит. И здесь какого-то холивара быть не может. Просто для мейнстрима он проигрывает в удобстве и скорости разработки, но C# однозначно проигрывает в скорости работы и во многих вещах это критично, так что ++ будут жить и жить.
Sylancer
Сообщение
16/01/2012 20:14
Копия темы
>Проблема вот в чем. Я привел список из 11 пунктов, которые меня не устраивают в Делфи (его можно >расширить) и в которых на мой взгляд он проигрывает .Net'у (и Java кстати тоже – вот в сравнении Java и >.Net все намного интереснее и однозначного ответа там точно нет, по крайней мере для меня). >Так вот, пока я не увидел аналогичного списка в пользу Делфи пусть даже в какой-то узкой области – в >основном, общие фразы. Вот это была бы интересная дискуссия. То есть, общие фразы Вам неинтересны, подавай конкретику ? Ок. Для выполнения Delphi-программ не нужен .NET Framework. Никаких соответствующих проблем с развертыванием и пользователями с ограниченным интернетом. Это раз. Delphi XE2 стоит существенно меньше Visual Studio. Экономия на стоимости рабочих мест. Это два. Паскалевский синтаксис преподавали на большей части СССР/СНГ, а кое-где преподают до сих пор. Цикл обучения программиста Delphi значительно короче и дешевле. Прямая выгода для компании. Это три. Delphi генерирует нативный, а значит, потенциально более быстрый код. Это четыре. Интеграция Delphi с сервисами операционной системы более естественна, так как осуществляется напрямую, а не через interop-слой. Попробуйте написать на C# нормальный тулбар для IE или расширение оболочки – замучаетесь. Я уже не говорю о системных задачах. Это пять. Уровень обеспечения кросс-платформенности у Delphi выше. Приложения WPF на Mono не работают. Это шесть. У Delphi-программ значительно ниже системные требования – многие приложения для электронной коммерции и АРМ до сих пор успешно работают на Windows 2000 и даже более ранних системах, где переход на другие версии Windows экономически нецелесообразен. Это семь. С рынком компонентов Delphi не сравнится ни одна аналогичная система – он доверху забит всевозможными компонентами, как платными, так и бесплатными. На просторах интернета можно отыскать практически любой нужный функционал. Это восемь. Итого – восемь против одиннадцати. Причем Ваши доводы в основном касаются чисто языковых и инструментальных средств, а мои растут ногами из менеджмента и экономической выгодности. Похоже как бы на спор программиста и менеджера – что лучше использовать. Вот и снова мы встаем перед вопросом – а целесообразно вообще спорить о подобных вещах, и если целесообразно, то в каком разрезе их рассматривать ? Да и потом, я не могу согласиться, что веб-сервисы, многозвенные приложения, LINQ, DI и DSL нужны для типичной настольной программы, а интеграция с базами данных у Delphi встроенная, кстати, и довольно неплохая. >Насчет клише: их-то я как раз старался избегать и писать только конкретику. Значит, мне показалось, что вот в этом проекте – www.free-lance.ru/project... Вы написали: "забудьте о Deplhi, если не хотите вечно клепать обработчики событий OnClick для очередной формочки с 2 grid'ами и 10 кнопочками" и клише тут и не пахнет ? >на десктопе его [Delphi] вытесняют Java и .Net 2 Еще под вопросом, у кого процент софта на десктопе выше – у Delphi или у .NET/Java. >1) скорее всего он [.NET Framework] уже скачан системой обновлений 2) 50 Мб скачать >сейчас не проблема" Именно из-за таких, образцовых, заблуждений пользователи качают продукты конкурентов.
nn-pugachev
Сообщение
19/01/2012 14:57
Копия темы
Вот сейчас и пройдемся по конкретике. Работал и на Delphi и на .Net проектах (не фрилансовых, корпоративка), могу ответить следующее: >Для выполнения Delphi-программ не нужен .NET Framework. Никаких соответствующих проблем с >развертыванием и пользователями с ограниченным интернетом. Это раз. начиная с висты .net в системе, начиная с xp sp3 он тоже в системе. в корпоративке он есть везде, где вин легальный. по домам он есть везде, где стоят видеокарты ati (Control Centre на нем), а также и еще куча софта на нем. На самом деле его сейчас мало где нет. >Delphi XE2 стоит существенно меньше Visual Studio. Экономия на стоимости рабочих мест. Это два. Visual Studio для небольших разработчиков либо бесплатен (Express), либо стоит $100 за 3 года (программа поддержки стартапов), причем платить нужно в конце срока, а не в начале. Ну и цена на XE2 в 28 килорублей – это дешево? даже сравнивая с ценой коробки VS Pro 2010 в 16 кило? >Паскалевский синтаксис преподавали на большей части СССР/СНГ, а кое-где преподают до сих пор. >Цикл обучения программиста Delphi значительно короче и дешевле. Прямая выгода для компании. Это три. Да, до сих пор преподают. Как положить кнопочку на форму, не думая об архитектуре. Свежеотучившийся студент, если он не работал на реальных проектах во время учебы – это чистый лист, которого еще учить и учить, на каком бы языке его ни готовили. >Delphi генерирует нативный, а значит, потенциально более быстрый код. Это четыре. ОЧЕНЬ спорное достоинство, учитывая JIT, компилирующий под текущую платформу, а не под абстрактную. Быстрее будет только очень жесткая математика. В остальном затыком производительности будет либо диск/сеть, либо пользователь, который не может тыкать кнопки быстрее, чем софтина думает. >Интеграция Delphi с сервисами операционной системы более естественна, так как осуществляется >напрямую, а не через interop-слой. Попробуйте написать на C# нормальный тулбар для IE или >расширение оболочки – замучаетесь. Я уже не говорю о системных задачах. Это пять. Смотря с какими сервисами. COM он и в африке COM – тут без разницы, что дельфи, что шарп. Для каких-то вещей действительно дельфи будет лучше (тот же шелл), но там еще лучше будут плюсы. >Уровень обеспечения кросс-платформенности у Delphi выше. Приложения WPF на Mono не работают. Это шесть. ну тут совсем уж не скажу, что плохо-хорошо с кроссплатформенностью GUI в .net, тот же qt есть себе. да только единственный вменяемый кросплатформенный gui – это web. остальное лучше делать под каждую платформу свое, иначе выглядит это ужасно. ну а раз свое, то и соответствующий инструмент испольуется. >У Delphi-программ значительно ниже системные требования – многие приложения для электронной >коммерции и АРМ до сих пор успешно работают на Windows 2000 и даже более ранних системах, где >переход на другие версии Windows экономически нецелесообразен. Это семь. успешно на таких системах работают арм тех же годов разработки :) на самом деле это тот же вопрос по гую, который делается соответствующим клиентской системе инструментом. и писать сейчас софт с расчетом на win2k – дорого, то есть либо опять уходим к универсальному решению – web, либо работаем с соответствующим инструментом. а сервера приложений на такие старые системы ни один вменяемый человек сейчас ставить не будет. >С рынком компонентов Delphi не сравнится ни одна аналогичная система – он доверху забит всевозможными >компонентами, как платными, так и бесплатными. На просторах интернета можно отыскать >практически любой нужный функционал. Это восемь. на codeplex.com давно смотрели? и это только opensource. про платные и говорить не буду. рынок .net компонентов давно обошел рынок компонентов для дельфи. популярность среды – тут ничего не сделаешь. Итого? гуи. то есть тупое рисование кнопочек. да поддержка старого кода. новый софт на дельфи – либо микропроекты, либо интеграция с legacy, где от нее никуда не денешься. в остальных местах – плюсы, java и .net по поводу количества софта, писанного на нете и дельфи на десктопах – зависит от применения десктопа. больше всего там софта на плюсах. но это не говорит о том, что на них писать удобнее или быстрее – это говорит о том, что на нем давно пишут, а переписывать все ради перехода на нет не всегда дешевле. но чем дальше – тем больше будет софта на нете. особенно с выходом восьмой винды, потому как писать два раза под arm и под интел одно и то же никто не будет.
Sylancer
Сообщение
20/01/2012 23:58
Копия темы
Для начала разберемся с фактами. >начиная с висты .net в системе Только .NET 2.0. При том, что среди программистов имеется тенденция использовать самые последние версии фреймворка. То есть, его обычно все равно приходится скачивать. >начиная с xp sp3 он тоже в системе. Не соответствует действительности. >Visual Studio для небольших разработчиков либо бесплатен (Express), либо >стоит $100 за 3 года (программа поддержки стартапов), причем платить нужно в >конце срока, а не в начале. Ну и цена на XE2 в 28 килорублей – это дешево? >даже сравнивая с ценой коробки VS Pro 2010 в 16 кило? Во-первых, купить Pro за 16 K – это еще надо постараться. Во-вторых, смотрим не только на ценник, но и на тип лицензии и думаем о том, можно ли использовать такую лицензию в коммерческих организациях. И лицензия BizSpark тоже когда-нибудь заканчивается, после чего приходится платить реальные деньги, либо прикрывать лавочку. В-третьих, настоящие возможности Visual Studio, связанные с платформой .NET, начинаются с редакций Premium, либо Pro с MSDN-подпиской, а это стоит в несколько раз больше. Так что средненькая, а не обрезанная по самое немогу версия VS2010 обойдется в лучшем случае в 50 К, но уж никак не 16. Так что средняя Visual Studio 2010 все-таки дороже Delphi XE.
Sylancer
Сообщение
21/01/2012 01:03
Копия темы
>Да, до сих пор преподают (Delphi). Как положить кнопочку на форму, не думая об архитектуре. Клише. То же самое можно сказать о любом языке. >ОЧЕНЬ спорное достоинство [нативный код], учитывая JIT, компилирующий под текущую >платформу, а не под абстрактную. Быстрее будет только очень жесткая математика. Образцы такой математики, тем не менее, встречаются на каждом шагу. И это одна из причин, почему некоторые проекты не торопятся переводить на управляемые "рельсы" .NET. По поводу компилятора, использующего особенности целевой платформы, я предлагаю не строить иллюзий – это настолько серъезная задача, что по силам лишь узкому кругу коммерческих компиляторов вроде Intel C++ Compiler, да и то в специальном режиме работы (Profile Guide). >успешно на таких системах работают арм тех же годов разработки :) >на самом деле это тот же вопрос по гую, который делается соответствующим клиентской >системе инструментом. и писать сейчас софт с расчетом на win2k – дорого, ... Win2K и XP продержались на рынке добрый десяток лет. Значительная часть софта все еще работает под этими системами. То же самое будет с Вистой, Семеркой и далее по нарастающей. Когда вы будете писать программы на восьмом фреймворке, вокруг будет полно народу, который в глаза не видел ничего старше пятого-шестого и компьютеры которых его просто не тянут. А программы на C/C++/Delphi запускаются и работают везде, их средние показатели по части производительности и требований к ресурсам другие. Вот почему это идеальный выбор практически для любого проекта, рассчитанного на массовость и совместимость. >на codeplex.com давно смотрели? и это только opensource. про платные и говорить >не буду. рынок .net компонентов давно обошел рынок компонентов для дельфи. >популярность среды – тут ничего не сделаешь. Соглашусь, я недооценил этот факт. Но все равно, с рынком компонентов Delphi мало что может потягаться. Поэтому данная среда остается востребованной, и весьма востребованной, пусть и в каких-то узких областях. Кстати, я не пытаюсь оспаривать нынешние роли .NET и Delphi на рынке программирования, но я против навешивания на Delphi ярлыка "RIP", как это сделал автор данной темы. >Итого? гуи. то есть тупое рисование кнопочек. да поддержка старого кода. >новый софт на дельфи – либо микропроекты, либо интеграция с legacy, где от нее >никуда не денешься. в остальных местах – плюсы, java и .net Если Вы еще не в курсе, поддержка старого кода – то, чем программист занимается большую часть времени. А рисование кнопочек непременно тупое, да. И хороший UI уже никому не требуется, да и денег за него не платят. >по поводу количества софта, писанного на нете и дельфи на десктопах – зависит от >применения десктопа. больше всего там софта на плюсах. но это не говорит о том, >что на них писать удобнее или быстрее – это говорит о том, что на нем давно >пишут, а переписывать все ради перехода на нет не всегда дешевле. но чем дальше – >тем больше будет софта на нете. .NET для некоторых вещей неестественен. Точно также, как Ruby для рисования фракталов или C/C++ для программирования веб-сервисов. Поэтому рискну предположить, что какие-то вещи никогда не будут писаться на .NET массово. Если только MS не переведет Windows под полное управление CLR, но этого даже на горизонте не видать. >писать два раза под arm и под интел одно и то же никто не будет. Когда-то точно также говорили про x64 и Itanium – ничего этого не случилось. В выигрыше окажется тот, кто раньше и качественнее других обеспечит поддержку этих платформ и сумеет предложить клиентам соответствующие сервисы на выгодных условиях. А будет ли это .NET или кто-то из натива – неизвестно.
tangueros
Сообщение
21/01/2012 06:43
Копия темы
Мне кажется, мы все немного уклонились от темы. Я сравнивал возможности фреймворков и вытекающие из них возможности и ограничения в типе и архитектуре софта. Цены, кривые обучения и тд и тп были out of scope (хотя наверное они имеют значения). В любом случае предлагаю тему закрыть, т.к. все равно все останутся при своем мнении. Небольшое замечание по поводу: "Если только MS не переведет Windows под полное управление CLR, но этого даже на горизонте не видать.". Посмотрите на . Это не совсем то, о чем вы говорите, но близко. А ограничения у .Net'a безусловно есть – к примеру на server-side я вообще планирую отказаться от него в пользу С++ и частично Java – все-таки скорость работы определяющий для меня фактор.
Sylancer
Сообщение
21/01/2012 19:19
Копия темы
0
WinRT я успел пощупать на Win8 Dev Preview – это та еще гадость. Ну и смысл написанного был в переводе самой Windows на CLR. То есть, хотя бы на уровне системного API. Тогда неуправляемые языки резко потеряли бы почву под ногами. А так да – тему пора закрывать. Всем успехов ! |
|
Выразить восторг, поругаться или предложить что-нибудь можно на форуме |
Для обсуждения этого сервиса так же есть темы на фрилансе по поиску , флудотопу ,и по удалённым сообщениям ,и по Актуальным/популярным темам , и по топу "кто кому больше наотвечал" |