Версия для мобильного
Я уже публиковал крупнейший в рунете обзор нововведений в 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 лет. А ваша? =)
Они бы лучше сделали поддержку 64-битных ОС, чем эту кроссплатформенность, которая будет еще лет так 5 допиливаться.
ОтветитьУдалитьА когда допилится, никому не будет нужна, все уже перейдут на Google OS. :-)
ОтветитьУдалитьНасколько я понимаю, для реализации 64-битности им всё-равно пришлось бы многое переписать. Многое из того, что они сейчас делают для введения кроссплатформенности. Впрочем, это только мои предположения.
А по моему Delphi скоро умрет. Никто здравомыслящий на Delphi не переходит. А те кто остался, рано или поздно переходят с нее на более продвинутые средства разработки приложений.
ОтветитьУдалитьПерешел на Visual Studio. C# куда удобнее язык чем Object Pascal.
ОтветитьУдалитьVS грузится вообще быстро, щас попробовал (первый запуск за сегодня), ушло 2 секунды.
Раньше я тоже, Delphi, Delphi, удобный синтаксис, все просто, посмотрел C# и понеслось, Delphi оказалась неудобной, и то что можно на WPF сделать без единой строчки кода, на Delphi пришлось бы писать ... ну-у, не мало. И это только самые простые вещи которые первыми пришли на ум.
И я даже не собираюсь обратно на Delphi переходить.
Да да, а визуального наследования как не было нормально так и нет в вашей визуал студии. То что вы легко переходите, говорит лишь об уровне на котором вы работали на Delphi.
ОтветитьУдалитьОчень интересная информация, спасибо.
ОтветитьУдалитьПо поводу будущего, туманно оно. D2007 должен быть после Delphi 7. А так время упущено, сейчас большие проекты очень проблематично перевести на 2009/2010, новые большие начинать на 2009/2010 не хочу т.к. прийдется держать 2 IDE и 2 набора компонентов.
Ага, а портировать приложение на НЕТ 1.1 на ВС2010 легко да? А может быть с НЕТ 2.0 легко?
ОтветитьУдалитьЯ на работе именно все свои проекты (самый большой 500 тыс. строк кода) портировал с 2006 на 2010 удачно, все работает уже почти год. Портировал именно для того что бы пересесть на новую среду и не разводить зоопарк.
На следующую версию - х64, кросплатформ переводить не планирую, думаю будет много гемороя, а главное особой выгоды нет.
Вообще придерживаюсь мнения, что проекты должны поддерживаться на той версии на которой создавались, если нет особых причин (например как поддержка W7 или необходимость х64)
Только что ради интереса сравнил время запуска (первый запуск за день):
ОтветитьУдалить1) Голая (без сторониих либ и расширений) MS Visual C# 2010 Express запустилась за ~18 секунд.
2) Delphi 2010 c кучей компонентов и экспертов - 22 секунды.
C# действительно выглядит интересней и удобнее.
ОтветитьУдалитьСловно все минусы Делфей были учтены и исправлены в C#.
А WPF в плане графической презентации рвёт визуальные Delphi-компоненты как тузик грелку.
Visual Studio действительно запускается в первый раз почти мгновенно (до главного меню), НО если попытаться открыть проект или пощелкать по меню -- начинаются тормоза и приходится некоторое время ждать.
ОтветитьУдалить* Поэтому все приложения до сих пор нативные на с++ или Delphi. А в WPF как не было визуального наследования так и нет. Как копипастили формы так и будут, а мы тем временем будем наследовать формы и фреймы и собирать приложение из универсальных модулей;
ОтветитьУдалить* Action как не было так и нет;
* Грид в стандартныой поставке WinForms как был убожеством мигающим так и остался;
* как жрало все это кучу ресурсов и тормозило так и продолжает.
* Fetch on Demand то сделали в ADO ? А то ведь не смешно уже.
Aleksey Timohin, очень странно, у меня профессиональная версия за 2 секунды запустилась. Сейчас проверил снова - в итоге 3 секунды.
ОтветитьУдалить>>> А WPF в плане графической презентации рвёт визуальные Delphi-компоненты как тузик грелку.
Что есть то есть! Суперская вешь. Это не только эффектно выглядит но и еще огромное количество плюсов дает, например простая разработка, отдельно от программиста. Т.е. дизайнер см по себе, программист сам по себе. Ну и есть инструмент для дизайнера позволяющий еще проще выполнять дизайнерские задачи.
А насчет тормозов, у меня нету, да и если приложение написать нормально, то и у пользователей все будет отлично. Взять бы тотже VS 2010 полностью перенесенный на WPF. Ну а VS 2008 был частично с использованием WPF, работает тоже быстро и без ошибок.
> C# действительно выглядит интересней и удобнее.
ОтветитьУдалитьСловно все минусы Делфей были учтены и исправлены в C#.
> А WPF в плане графической презентации рвёт визуальные Delphi-компоненты как тузик грелку.
Ну и то же теперь, неужели переходить на C#? :)
> А в WPF как не было визуального наследования так и нет. Как копипастили формы так и будут, а мы тем временем будем наследовать формы и фреймы и собирать приложение из универсальных модулей;
ОтветитьУдалитьCopy-Paste конечно зло. Но и визуальное наследование особо удобным я бы не назвал. По крайней мере в том, что касается фреймов. Повозившись с разными багами, я перестал класть фреймы на формы в дизайнере, заменив на динамическое создание в run-time. Так намного проще контролировать ситуацию.
Мне даже сложно представить ситуацию, когда визцальное наследование может быть полезно.
Сергей, у меня не самый быстрый комп. Я лишь хочу подчеркнуть, что на моём компе, время запуска VS2010 и Delphi2010 практически одинаково.
ОтветитьУдалить>Ну и то же теперь, неужели переходить на C#? :)
Keeper, есть ещё Delphi Prism. ;)
Ну вот, если будет выбор между C# и Delphi Prism - я выберу первое :)
ОтветитьУдалитьРечь именно об обычном Delphi. Есть же у него какие-то преимущества (или планируются)?
> Насколько я понимаю, для реализации 64-битности им всё-равно пришлось бы многое переписать.
Все равно мне это кажется более насущной проблемой, чем полукроссплатформенность. Средненькое приложение для Linux можно и в том же Lazarus'е сделать, а серьезное портировать думаю и не удастся. А 64-битные платформы и приложения это уже почти норма.
> Они бы лучше сделали поддержку 64-битных ОС, чем эту кроссплатформенность, которая будет еще лет так 5 допиливаться.
ОтветитьУдалитьЯ думаю лучше они пусть кроссплатформенность "пилят", т.к. особо не вижу в поддержке 64-битных ОС чегото действительно нужного (производительность увеличится ~ < 10% - всего то)
Если они "допилят" за 2 года это будет прекрасно.
Анонимный - проблема 64-битности более актуальна для тех кто пишет библиотеки. 64-битные приложения не дружат с 32-битными DLL-ками.
ОтветитьУдалитьИ не факт, что за 2 года они сумеют стабильную удобную кроссплатформенность.
> Copy-Paste конечно зло. Но и визуальное наследование особо удобным я бы не назвал. По крайней мере в том, что касается фреймов. Повозившись с разными багами, я перестал класть фреймы на формы в дизайнере, заменив на динамическое создание в run-time. Так намного проще контролировать ситуацию.
ОтветитьУдалитьДобро пожаловать в java ))) Там ваще с GUI туго )
>И не факт, что за 2 года они сумеют стабильную удобную кроссплатформенность.
ОтветитьУдалитьБыл на конференции по D2010, между тем было сообщено что большие ресурсы кинуты на это. Так что посмотрим.
После реализации, я думаю это будет жёстким аргументом в пользу Delphi для тех кто перешёл С#
>>После реализации, я думаю это будет жёстким >>аргументом в пользу Delphi для тех кто перешёл С#
ОтветитьУдалитьНе думаю, что это будет таким уж весомым аргументом...Linux он конечно развивается, растёт и т.д., но если взглянуть на процент пользователей которые сидят ТОЛЬКО в Linux или используют ТОЛЬКО MacOS, то можно сказать, что Embarcadero пробует выстрелить из пушки по мухе (даже не по воробью). Я конечно рад, что намечается кроссплатформенность, т.к. сейчас приходится ковыряться то в Delphi, то в Лазаре, но согласен с Keeper - лучше бы больше сил кинули на 64-битность.
Ололо! Холивар! =)
ОтветитьУдалить> Если я правильно понял, у автора получилось скомпилировать только консольную программу под OS X. Попытка скомпилировать GUI-программу успехом не увенчалась.
O_O Прямо на Виндавс получилось? Не верю!
> А вы как думаете через сколько лет стоит ждать стабильно работающую версию Делфи с поддержкой кроссплатформенности для создания GUI приложений?
Хм... Java до сих пор ниачём в плане Native Look and Feel, а Qt уже столько лет... Вообщем, если Майя были правы, не видать вам кросс-ОС Delphi как своих ушей! =)
Из плюсов 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 блоки для меня приравнивается к совету писать программы без ошибок ;)
Codegear/Embarcadero живут под девизом "Ни года без новой версии Delphi" ? Лучше бы действительно ошибки исправляли, чем каждый сервиспак называть новым именем и брать денег за апгрейд.
ОтветитьУдалитьПосле покупки Delphi компанией Embarcadero дела пошли на поправку.
ОтветитьУдалитьчем лучше Delphi чем C#?
Delphi нативный язык, C# для полускриптового дот нета. Отсюда и рога - тормоза, большие размеры и ресурсы у C# и соответсвующие ограничения на скоростные алгоритмы, на невозможность создания cgi и др. плюс обязательное наличие дотнет.
Наверное повторюсь, но я до сих пор не понимаю чего они так к GUI привязались. Сделали ли бы для начала хотя бы компилятор консольных приложений/библиотек - и то было бы хорошо.
ОтветитьУдалитьАнонимный комментирует...
>чем лучше Delphi чем C#?
У разных пользователей - разные задачи. Я, например, пишу GUI для баз данных, и скоростные алгоритмы мне до фени (лишь бы работа с БД шла быстро).
>> Сделали ли бы для начала хотя бы компилятор консольных приложений/библиотек
ОтветитьУдалитьЭм, что за бред? Собственно он существует еще с самой первой версии Delphi 1 :). Хочешь пиши с GUI, а хочешь без. Хочешь компили dll. Как это можно было не заметить?
У меня консольный cgi на сервере крутится, писал его на Delphi. Быстрый exe, - то что нужно.
Я представляю Fruity Loops Studio (написана на Delphi), мощная студия для создания музыки, с кучей секвенсоров, которая написана на C# - тормоза обеспечены.
ОтветитьУдалитьНу или тот же фотошоп, на C#. :)
Анонимный ляпнул:
ОтветитьУдалить> Эм, что за бред?
Деточка, речь идёт о кроссплатформенном консольном компиляторе, кросс-плат-фор-менном!
Lazarus рулит.
ОтветитьУдалитьhttp://isdelphidead.com/
ОтветитьУдалитьDelphi приносит мне дофига денег. Холиворьте дальше :)
MicroISV
>>> Из плюсов Delphi к примеру
ОтветитьУдалитьВы не поверите, но на самом деле это её минус.
Это не более чем наследие старых времён, когда в программах не было глобального обработчика необработанных исключений.
Интересно, а в VS также легко, удобно и мощно реализована многозвенная архитектура доступа к БД? Я имею в виду что-то похожее на DataSnap. Давно использую эту технологию в проектах - просто класс. В IDE 2010 - очень сильно усилилась DataSnap. Embarcadero так держать. Кому интересно на русском не много о DataSnap: http://www.delphi2009.ru/Delphi_2010_DataSnap_RUS.pdf
ОтветитьУдалитьНасчет якобы "недостатков" визуального наследования.
ОтветитьУдалитьНе надо смешивать визуальное наследование форм/фреймов с глюками, связанными с размещением фреймов в дизайнтайме. Подобные высказывания говорят о незнании премета.
Не нравятся фреймы - не используем, но визуальное наследование к проблемам размещения фреймов - никаким боком.
Лично я верю в Embarcadero.
ОтветитьУдалитьПока мелкомягкий не портирует .NEТ как JAVу - за ним нет будущего(((
Фигня это китайцы над delphi 2010 издеваються а разработчики 2011 невыускали
ОтветитьУдалить> Фигня это китайцы над delphi 2010 издеваються а разработчики 2011 невыускали
ОтветитьУдалитьНе выпускали. Но выпустят. И UCL там будет. =)
Пара ссылок на официальный сайта, где упоминается Fulcrum
ОтветитьУдалитьhttp://blogs.embarcadero.com/abauer/2010/01/26/38908
http://cc.embarcadero.com/item/27675
Ну а самое подробное (полу)официальное описание Фулкрума здесь:
http://en.wikipedia.org/wiki/Borland_Delphi
Гимаев Наиль, спасибо!
ОтветитьУдалитьВеры в Дельфи у меня лично больше нет.
ОтветитьУдалитьТолько разве что "спортивный интерес" остался.
А так, перелез на C# и всем настоятельно советую.
Есть у МелкоМягких свои тупости и минусы, но плюсов у VS+C#+.NET на порядок больше.
IMHO: Последние версии Дельфей выглядят убогенько на фоне C#.
Дельфи явно остаются в роли неудачного догоняльщика и в идеологическом и в технологическом плане.
Крайне не рекомендовал бы начинать новые проекты на нем. К тому же и специалистов уже проблематично набрать в команду - почти вся молодежь на C# и на Жабе сидит. А что будет через пару-тройку лет?
А вот поможет ли Дельфям кросплатформенность вылезти из полной ж...?
- Не уверен.
MacOS X - это все же больше не офисная платформа. Там мордочки для БД и прочий стандартный Дельфи-софт не особо востребованы.
К тому же там есть вполне функциональный и дешевый IDE для Object-C заточенный под особенности данной OC.
Linux - ну не знаю... по-моему это не в духе GNU GPL. Это сообщество все же живет по своим законам.
>чем лучше Delphi чем C#?
ОтветитьУдалитьВсегда сложно спорить о вкусе устриц с человеком, который их не ел.
Может и глупо в сотый раз, но все же...
>Delphi нативный язык, C# для полускриптового дот нета.
Delphi - "нативный язык"? А с терминами-то у вас явная беда :)
А .NET не "скриптовый" и не "полускриптовый". Более правильное понятие - отложенная финальная компиляция и оптимизация в конечный код платформы.
В конечном же счете С#-повый код выполняется найтивно и при этом он очень и очень неплохо оптимизирован. Мы сравнивали финальный ASM от Дельфей и от C# - разницы ни какой. "Плавающую точку" .NET оптимизирует даже получше Дельфей.
Кроме того можно создать и уже полностью откомпилированный (найтивный) образ.
>Отсюда и рога - тормоза, большие размеры и ресурсы у C#
???
В основном размеры, ресурсы, рога, тормоза в C# будут только от "горе-разработчиков" плохо знающих основные принципы работы с данной средой.
Впрочем, так же, как и на Дельфях.
>и соответсвующие ограничения на скоростные алгоритмы, на невозможность создания cgi и др.
На скоростные алгоритмы ограничений в C# нет.
Чисто вычислительные алгоритмы могут выполняться даже быстрее, чем на Дельфях.
А вот cgi я бы и на Дельфях делать КРАЙНЕ не рекомендовал бы. Для cgi нужен например VC++ с его ШИКАРНОЙ оптимизацией.
> плюс обязательное наличие дотнет.
IMHO: Это вообще уже "детско-садовский аргумент".
Неужели в 2010 году это кого-то может всерьез напугать, да еще и на Win платформе? ;)
64 бита обещают в этой версии тоесть 2011
ОтветитьУдалить>IMHO: Это вообще уже "детско-садовский аргумент".
ОтветитьУдалить>Неужели в 2010 году это кого-то может всерьез >напугать, да еще и на Win платформе? ;)
Это может напугать тех кто понимает, что для того что бы все .net проги работали им необходимы абсолютно все фрайьворки.
>Delphi - "нативный язык"? А с терминами-то у вас явная беда :)
ОтветитьУдалитьА .NET не "скриптовый" и не "полускриптовый". Более правильное понятие - отложенная финальная компиляция и оптимизация в конечный код платформы. ...
Я х.з. , как бы ты это не называл бы "отложенная финальная компиляция" или как то иначе С#-е приложения тормознутее аналогичных делфёвых.
Попробуйте сделать тест Заполнения массивов объектов, чтения, удаления, Больших! массивов. и Сравни. Память и Скорость.
Как Вы думайте приложения класса Фотошопа или Корелдро реально написать на С#? и как они будут работать?))
Кстати "отложенная финальная компиляция и оптимизация в конечный код платформы" это и есть транслятор а соответственно "скриптовый"
ОтветитьУдалить>А по моему Delphi скоро умрет. Никто здравомыслящий на Delphi не переходит. А те кто остался, рано или поздно переходят с нее на более продвинутые средства разработки приложений.
ОтветитьУдалитьИнтересно MS приплачивают парням, кто это пишет?
))
> Это может напугать тех кто понимает,
ОтветитьУдалить> что для того что бы все .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# и обогнал Дельфи, причем существенно.
Именно поэтому-то, а не по чему-то другому Дельфи и загибаются.
>>> Я х.з. , как бы ты это не называл бы "отложенная финальная компиляция" или как то иначе С#-е приложения тормознутее аналогичных делфёвых.
ОтветитьУдалитьКак правильно заметил другой анонимус, это показатель того, что вы не знаете среду, в которой работаете. Примерно так же, как если бы вы создали массив из нескольких тысяч объектов размером 12 байт в Delphi и ругались бы, что это в 15-20 раз тормознее "аналогичного" кода C (где были использованы аналоги дельфёвых record-ов).
.NET - это именно нативный код. Только компилируется он на целевой машине, а не машине разработчика, что и обеспечивает его кроссплатформенность.
что и обеспечивает его кроссплатформенность - ? Где? на Мас, на Lin, ... N, или Только Win32, Win64. Какая хорошая кросс, меж платформенность. )))
ОтветитьУдалить> Подобные приложения крайне не желательно писать как на С#, так и на Delphi.
ОтветитьУдалитьПодобные вещи можно писать на Delphi. И будут они работать ровно. (С учётом грамотного программиста)
>Если же тебя это время так волнует, то ты можешь создать "найтивные" ...
ОтветитьУдалитьГоспода, как Вы думайте почему MS не пишет свои проложения на .Net, {ведь С# же довольно приличный язык , современный, удобный, кроссплатформенный, разраб. с 2001 года (уже почти 10 лет)}, типа Word, Excel, ... N ( только шарепоит на нём из тех чем я пользуюсь) ?
Или всётаки он для определенного класса приложений?
> Господа, как Вы думайте почему MS не пишет свои проложения на .Net,
ОтветитьУдалитьВообще-то пишет. А дедушка MS Office наверное имеет слишком большую и отлаженную базу кода, чтобы её просто так брать и выбрасывать переписывая на новой платформе.
> Господа, как Вы думайте почему MS не пишет свои проложения на .Net
ОтветитьУдалитьКак вы себе представляете перенос проектов с 20-летней историей, огромной базой кода и кучей хаков совместимости под .NET?
> Где? на Мас, на 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 будет оптимальным выбором стремительно сужается (если не брать поддержку старых проектов).
Хороший ответ))
ОтветитьУдалитьИз Ваших убедительных слов видно что на текущий момент времени 'VС++' + C# явно обгоняют Delphi или Delphi где-то стоит между ними, смотря с какой стороны смотреть)).
Ну а как Вы думайте что будет лет так через 5-7?, с теме же тенденциями развития?
Я думаю что для Delphi эбакадеро
A) "cдерет" что есть нужное у C#
Б) Станет РЕАЛЬНО кроссплатформенной (без "скриптовой" начинки)
>Из Ваших убедительных слов видно
ОтветитьУдалить>что на текущий момент времени '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 лет найти будет крайне тяжело.
Ну да время покажет...
В любом случае, понаблюдать будет интересно.
>Для примерного ответа взгляните на Delphi.NET.
ОтветитьУдалитьПомоему он официально умер.
>Короче, я не разделяю вашего оптимизма по поводу будущего Дельфей, и не думаю, что у относительно небогатой Embarcadero хватит сил тягаться с MS на одном поле, если они будут в роли догоняльщика (как сейчас).
У Борлонда в 1995-2002, хватило же сил тягаться. Стратегия простая, посто "воруй" плюсы и всё, чем они частично и занимаются.
>Я не верю, что дельфи программисты начнут рисовать интерфейс из рюшечек, как это надо для любителей MacOS.
Я имел виду что. Если перекомпиляция с WIN на MAC и Lin займёт мало времени(и код не нужно будет менять), то на рюшечеки можно положить. Грех этим не пользоваться... (При этом надо помнить что WIN платный а с пиратками начинают бороться активнее,. альтернатива должна быть)
>Скорее всего, Дельфи займут очень узкую нишу.
Да и специалистов через 5-7 лет найти будет крайне тяжело.
Не разделяю вашего пессимизма)
Интересно, что Вы думайте о MONO ?
>Я не верю, что дельфи программисты начнут рисовать интерфейс из рюшечек, как это надо для любителей MacOS.
ОтветитьУдалитьНа делфи под виндой рюшечки рисуются достаточно просто. И не вижу никакой проблемы рисовать рюшечки под маком
> У Борлонда в 1995-2002, хватило же сил тягаться.
ОтветитьУдалить> Стратегия простая, посто "воруй" плюсы и всё, чем они частично и занимаются.
Не знаю у кого там воровал Борланд, но первые версии Дельфей были реально прогрессивнее, чем у конкурентов.
Видимо, у них тогда были свои мозги и идеи.
>Я имел виду что. Если перекомпиляция с WIN на MAC и Lin займёт мало времени
>(и код не нужно будет менять), то на рюшечеки можно положить.
>Грех этим не пользоваться... (При этом надо помнить что WIN платный
>а с пиратками начинают бороться активнее,. альтернатива должна быть)
Подумайте, что вы говорите. Если с пиратками начинают бороться, то MacOS тут уж точно не поможет.
При такой высокой цене на Apple ни какие организации не будут их закупать в качестве офисных компьютеров.
Они как были домашними и дизайнерско-музыкантскими так такими и остаются.
Посмотрите на рынок программного обеспечения для MacOS.
Что вы на Delphi можете предложить на этом рынке?
Остается только Linux.
Может быть..., но уже был Kylix и благополучно умер. Причина оказалась все та же - очень маленький спрос.
А ведь это было на подъеме Linux-мании.
>>Скорее всего, Дельфи займут очень узкую нишу.
>>Да и специалистов через 5-7 лет найти будет крайне тяжело.
>Не разделяю вашего пессимизма)
Так уже тяжело. Молодежь в основном ориентируется на более новые технологии.
>Интересно, что Вы думайте о MONO ?
Думаю, что пока сама MS не захочет выпускать FrameWork-и для определенных платформ, лучще не связываться с такими поделками как MONO.
А вообще, пишите на Delphi пока считаете это для себя наиболее эффективным.
>Подумайте, что вы говорите. Если с пиратками начинают бороться...
ОтветитьУдалить-альтернатива должна быть - Я имел виду MacOS
-пиратками начинают бороться - Я имел виду бесплатный Linux
>Может быть..., но уже был Kylix и благополучно умер. Причина оказалась все та же - очень маленький спрос.
На сколько мене известно Kylix был на QT которая в то время была платная, и получалось Борланд здесь облажался, т.к. такое решение никому ненужно. Сейчас же ситуация изменилась, насколько мне известно QT сменил тип лицензии, и стал бесплатным.
>Думаю, что пока сама MS не захочет
Уверен что она никогда не захочет ))
> -альтернатива должна быть - Я имел виду MacOS
ОтветитьУдалитьВсегда хорошо иметь альтернативу. Кто против-то?
Я лишь усомнился в связке MacOS+Delphi.
Вам же это теоретически нужно, чтобы например быстро перевести приложение на MacOS.
Вопрос звучит собственно - А кому-нибудь нужно там ваше приложение?
Или вы собрались очередной красивый графический пакет на Дельфях писать?
Не знаю, но по моим прогнозам рынок Дельфевых приложений будет очень и очень скуден на Apple.
Тем более, что Дельфи стоит приличных денег, а Apple снабжает разработчиков "бесплатными" средствами типа Xcode.
>-пиратками начинают бороться -
>Я имел виду бесплатный Linux
Но в 99% офисах его пока как не было так и нет...
>А кому-нибудь нужно там ваше приложение?
ОтветитьУдалитьНу это наверно вопрос к больше к маркетингу, чем к возможностям сред разработки.
Например я пользуюсь программой для удалённого подключения TeamViewer, она удобна и проста, не требует инсталляции, ей не нужен .net и перед запуском накатить на Win какие нибудь обновления. Она просто тупо работает(я её не рекламирую, моё мнение). И когда я через неё управлял Macoм удалённо c Win я испытал восторг. Я считаю это качественное ПО. Нужно ли оно там? Незнаю, Мне нужно.
> Ну это наверно вопрос к больше к маркетингу,
ОтветитьУдалить> чем к возможностям сред разработки.
Ну что ж, будет интересно посмотреть, чем пополнится MacOS с появлением там Дельфи.
Если это вообще произойдет, конечно...
По поводу 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-разрядности.
> Поэтому на 64-bit Delphi, как на бизнес-идею, я пока смотрю с подозрением.
ОтветитьУдалить> "На вырост" это может быть хорошим заделом, но когда этот вырост произойдет...
Embarcadero правильно делает, что смотрит в сторону 64-bit.
Это уже реальность, а не просто идея "на вырост". Объясню почему:
Количество компьютеров как стационарных так и ноутов с 64-битной системой растет.
Конечно же, далеко не всем пользователям для работы так уж нужна память более 3 гигов, за исключением тех, кто профессионально работает с обработкой видео и/или графики.
Но вот количество серверов, на которых 64-bit и памяти больше 4 гигов растет еще быстрее. И это вполне оправдано.
Кто-нибудь может сказать, что x86 приложения итак хорошо выполняются на 64-битных платформах.
Так то оно так, но во-первых, нельзя забывать, что потеря хоть и небольшая производительности все же есть за счет WOW64
Во-вторых, сопряжение 32-битных приложений с 64-битными библиотеками и приложениями может нести с собой определенный и местами вполне серьезный гемор.
В-третьих - отсутствие 64-бит в связи с вышеперечисленным - это плохо с точки зрения маркетинга и планирования при организации нового проекта.
Поэтому, даже если вам конкретно сейчас 64-бит не особо надо, то через пару лет, когда вы допишете свое творение, у большей половины уже эти 64-бит будут стоять по умолчанию...
> Во-вторых, сопряжение 32-битных приложений с 64-битными библиотеками и приложениями может нести с собой определенный и местами вполне серьезный гемор.
ОтветитьУдалитьЧасть разработчиков ушла с Delphi именно по этой причине. Только в данном случае ситуация обратная, разработчики на Delphi не могут создавать библиотеки работающие с 64-битными приложениями.
Сама по себе 64-битность, нафиг не сдалась. Но иногда без её поддержки просто никак.
> Часть разработчиков ушла с Delphi именно по этой причине.
ОтветитьУдалить> Только в данном случае ситуация обратная, разработчики на Delphi
> не могут создавать библиотеки работающие с 64-битными приложениями.
> Сама по себе 64-битность, нафиг не сдалась.
> Но иногда без её поддержки просто никак.
Вот именно.
Поэтому 64-бит для Дельфей могут оказаться даже более актуальными, чем абстрактые мечтания на тему:
"Вот уже скоро будет версия для MacOS, тогда мы всем покажем!" :)
Ну пост от 15.6.09 почти год, всё меняется...
ОтветитьУдалитьЗначит Embarcadero на правильном пути ))
>> плюс обязательное наличие дотнет.
ОтветитьУдалить> IMHO: Это вообще уже "детско-садовский аргумент".
> Неужели в 2010 году это кого-то может всерьез напугать, да еще и на Win платформе?
Кхм... скажу по скромному опыту, найдётся 1000 и 1 причина почему FrameWork не будет работать\функционировать\устанавливаться\переустанавливаться на рабочей машине. Думаю ситуация исправится только тогда, когда он сам станент неотъемлемой частью ОСи.
> А сам Дельфи вообще очень средненько оптимизирует в машинный код (иногда, на порядок хуже VС++)
Информация не актуальна, суровые 90-е уже давно прошли. Кстати, давненько где-то натыкался на подобное исследование, сравнивался код генерируемый компиляторами Делфи и Cи++, так вот для некоторых ситуаций Cи++ генерировал совершенно невменяемое нечто (но думаю эта информация тоже устарела).
> Да и лежащая под этим паскалевская необходимость объявления всего сверху вниз лишь мешает.
Хэх, видимо вам в жизни никогда не приходилось разбираться в чужих проектах.
Везунчик :D
> При такой высокой цене на Apple ни какие организации не будут их закупать в качестве офисных компьютеров.
Наглядный пример - корпорация Google, на текущий момент она полностью отказывается от ОСи Windows, как альтернативу планируют использовать MacOS X и Linux.
> Извиняюсь за подобные аналогии, но на мой (бизнес-) взгляд рынок 64-разрядных приложений (создаваемых на Delphi) практически равен нулю.
Да нет, вы учитываете десктопы и совершенно забываете про сервера.
> Кхм... скажу по скромному опыту, найдётся 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 задалбывало.
> Да нет, вы учитываете десктопы и совершенно забываете про сервера.
ОтветитьУдалить+ много.
> Наглядный пример - корпорация Google
Пару лет назад Google зарабатывал столько, что не успевали придумать куда вложить всё заработанное. Пруфлинк.=)
> А вообще, по личному скромному опыту всегда найдется куча причин, по которым что-нибудь, где-нибудь не заработает как надо.
И чем больше в цепи звеньев, тем выше шансы того, что это случится, и тем сложнее будет вычислить причину.
> Приходилось довольно часто. А поэтому даже и постоянное прыгание между interface и implementation задалбывало.
А я вот так и не могу толком привыкнуть к чтению C# исходников. В этом плане Delphi для меня удобнее. Сначала изучил только интерфейсную часть, потом, если надо и реализацию. Впрочем, я не использовал Сворачивание блоков кода и диаграммы.
а мне вот приходиться привыкать к Delphi-коду, в конторе тьма наработок в .pas - я вешаюсь!
ОтветитьУдалитьодно чего стоит, для for переменную-итератор отдельно объявлять. Еще конструкции Ovject:=Type.Create; - парюсь постоянно.
А в принципе язык хороший.
А вот RAD Studio - просто калл, а не IDE!
COBOL, FORTRAN, ADA, PL/1 тоже еще кто-то, где-то использует. И даже обновленные версии компиляторов иногда выходят.
ОтветитьУдалитьТеперь в этом ряду и DELPHI
Ключевой вопрос: Вы что, хотите быть специалистами по древним языкам?
Ну тогда Delphi - это безусловно ваш выбор.
Подумайте только, кому и где вы будете нужны завтра?
Сегодня в мире Windows все крутится вокруг .NET технологий, завтра тоже. Послезавтра, возможно, будет что-то новое.
Но вокруг Delphi уже точно ничего особенного крутится не будет.
Люди уже оперируют такими вещами как LINQ и Entity Framework, пользуются регулярными выражениями, не первый год компилируют под девайсы и прочее и прочее,
а дельфийцы в это время все гадают будет у них в следующей версии 64-бит или еще на годик отложат...
:D
"Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда–то попасть, надо бежать как минимум вдвое быстрее!" (Алиса в Зазеркалье)
> а дельфийцы в это время все гадают будет у них в следующей версии 64-бит или еще на годик отложат...
ОтветитьУдалитьОчень остроумно подмечено. Уже 3й или 4й год гадаем. =)
> Ключевой вопрос: Вы что, хотите быть специалистами по древним языкам?
Хороший программист - он на то и программист, чтобы уметь программировать без привязки к конкретному языку. Имхо, главное - следить за тенденциями.
Как не раз писали западные блоггеры, если нанять хорошего Delphi-программиста для программирования под .NET то он выучит C# за пару месяцев. А если нанять .NET-чика и посадить его на Delphi - он не захочет учиться вообще.
#Как не раз писали западные блоггеры, если нанять хорошего Delphi-программиста для программирования
ОтветитьУдалить#под .NET то он выучит C# за пару месяцев. А если нанять .NET-чика и посадить его на Delphi
# - он не захочет учиться вообще.
Что вполне естественно со стороны .NET-чика, поскольку нафига ему вообще учить эти дельфевые рудименты.
Википедия: РУДИМЕНТ, -а, муж.
1. Недоразвитый, остаточный орган, бывший полноценным на предшествующих стадиях существования организма (спец.).
:)
>> Как не раз писали западные блоггеры, если нанять хорошего Delphi-программиста для программирования под .NET то он выучит C# за пару месяцев. А если нанять .NET-чика и посадить его на Delphi - он не захочет учиться вообще.
ОтветитьУдалить> Что вполне естественно со стороны .NET-чика, поскольку нафига ему вообще учить эти дельфевые рудименты.
Такой .NET-программист в недалёком будущем сам станет РУДИМЕНТОМ (Недоразвитый, остаточный орган, бывший полноценным на предшествующих стадиях существования организма) ;-)
#Такой .NET-программист в недалёком будущем сам станет РУДИМЕНТОМ
ОтветитьУдалитьБезусловно станет. Это необратимо.
Количественное, как всегда, перерастет в качественное. Появятся новые технологии на новом уровне и новом витке развития.
И .NET станет историей.
А пока историей становится Delphi.
Только если кто-то по лени, по наивности или по привычке цепляется за старое, то это не есть хорошо и не от большого ума. И это уж точно не прагматично и не практично.
> если кто-то по лени, по наивности или по привычке цепляется за старое, то это не есть хорошо и не от большого ума
ОтветитьУдалитьЕсть ещё такая вещь как опыт и наличие работы. Зачем менять хорошую работу на Delphi на фиг знает какую на .Net? :) Особенно, если работа действительно хорошая. ;)
>Сегодня в мире 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 можно назвать витком развития?
> По мимо мира 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 еще где-то используется. Значит, где-то и Дельфи пристроят.
В верхнем листинге не прошли знаки больше меньше в объявлении дженерик листа. Очевидно были проглочены, как тэги.
ОтветитьУдалитьПоэтому, заменю их на обычные скобки
List(Employers) emp = new List(Employers)();
>А при чем здесь Apple?
ОтветитьУдалитьИли вы тоже надеятесь, что выход Delphi для Apple что-то изменит в раскладе Delphi vs .NET? ;)
Возможно что да.
>Я вот LINQ использую частенько, поскольку это упрощает код и уменьшает количество лишней писанины. ...
LINQ - Класная вещь, Интересно она только под MS SQL Serv, или на других СУБД тоже работает?
>> А при чем здесь Apple?
ОтветитьУдалитьИли вы тоже надеятесь, что выход Delphi для Apple что-то изменит в раскладе Delphi vs .NET? ;)
> Возможно что да.
Не исключено, ниша пока не занята.
> LINQ - Класная вещь, Интересно она только под MS SQL Serv, или на других СУБД тоже работает?
ОтветитьУдалитьLINQ вообще не завязан на БД. Теоретически он должен уметь работать с массивами, списками, XML и любыми Базами Данных. Но практически я с ним не работел, поэтому реального положения дел не знаю.
> LINQ - Класная вещь, Интересно она только под MS SQL Serv,
ОтветитьУдалить> или на других СУБД тоже работает?
LINQ, как уже написал Aleksey Timohin, не предназначен только для БД.
В этом-то собственно и есть его удобства.
Собственно для БД есть "LINQ to ADO.NET" и "LINQ to SQL".
А, например, "LINQ to Object" позволяет делать запросы к спискам и коллекциям, сильно помогая в работе с ними. Простенький пример я уже привел выше.
Общий смысл в этом - унифицировать и упростить выборку и манипуляцию с данными из разнородных источников.
> Не исключено, ниша пока не занята.
Может быть. Хотя, лично я сильно сомневаюсь, но может быть...
>А, например, "LINQ to Object" позволяет делать запросы к спискам и коллекциям, сильно помогая в работе с ними. Простенький пример я уже привел выше.
ОтветитьУдалитьСпасибо за ответ, Эта тема мне что-то напомнила QCL (в BOLD/ECO), только там можно было работать только с собственными объектами.
Хорошо бы, было бы, если Ембакадеро "слижет" LINQ )
Это сейчас Microsft рекомендует и продвигает свой язык C#. Сейчас вот читаю статью -
ОтветитьУдалить"Microsoft разрабатывает новый язык программирования Axum"
Поклонимся им. Скоро C# устареет и MS будет рекомендовать переходить на Axum. Для них это бизнес.
Подумайте об истории всевозможных стратегий доступа к данным, разработанным Microsoft. ODBC, RDO, DAO, ADO, OLEDB, теперь вот ADO.NET - И все абсолютно новые! Может это было вызвано технологической необходимостью? Может это результат некомпетентной группы проектирования, которой необходимо придумывать по-новой доступ к данным каждый чертов год? (Возможно, это в самом деле так.) Но конечный результат - всего лишь огонь для прикрытия. Конкуренты не имеют никакого другого выбора, кроме как тратить своё время, переписывая код под новые библиотеки и поспевая за лидером - время, которое они не могут использовать для создания новых возможностей.
Почитайте вот эту статью.
http://russian.joelonsoftware.com/Articles/FireAndMotion.html
Менее успешные компании - это те, кто тратит слишком много времени ловя каждое движение Microsoft, гадая в каком направлении она пойдёт дальше. Люди начинают волноваться по поводу .NET и решают полностью переделать архитектуру под .NET, потому что они думают, что они вынуждены это сделать. Microsoft ведёт по вам огонь, и это всего лишь огонь прикрытия для того чтобы они могли двигаться вперёд, а вы нет. Таковы правила игры, дружок
ОтветитьУдалитьДжоеля почитать иногда познавательно. Он мужик весьма умный. Да только...
ОтветитьУдалить> ... 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, пока ей не надоест нести убытки от поддержки Дельфей.
А самое смешное, что у нас как раз Дельфи очень любят (особенно старые перд...), но практически никто ее не покупает (типа очень дорого) ;)
> Чего нельзя сказать о BDE от Borland. Который на этом фоне был практически мертворожденным. Его конечно тоже использовали кое где по началу, но почти все достаточно быстро отказывались в пользу найтивных решений или решений от MS.
ОтветитьУдалитьВот тут вы неправы, в нашей конторе до сих по используют BDE для MS SQL, при всём его неудобстве и моральной старости по сравнению с ADO и DBX+CDS, он и по скорости {гдето в 2 раза} и по использ. памяти обгоняет. (из за этого аргумента попытка перейти на ADO провалилась, кончилось тем что написали свой инсталлятор для BDE)
>А самое смешное, что у нас как раз Дельфи очень любят (особенно старые перд...), но практически никто ее не покупает (типа очень дорого) ;)
Это вы точно подметили, хочу отметить что молодые перд... , тоже))
Из russian.joelonsoftware.com в тему про зависимости ))
ОтветитьУдалить... Другой лагерь назван мною лагерем журнала MSDN: по имени журнала для разработчиков, полного увлекательных статей обо всех способах отстрела собственной ноги при помощи продуктов Microsoft и собственного программного обеспечения. Лагерь журнала MSDN всегда пытается убедить вас применять новые и сложные внешние технологии, такие как COM+, MSMQ, MSDE, Microsoft Office, Internet Explorer и его компоненты, MSXML, DirectX (пожалуйста, самую последнюю версию), Windows Media Player и Sharepoint... Sharepoint! У кого он есть? Пышный наряд внешних зависимостей, каждая станет причиной сильнейшей головной боли, когда вы отправите ваше приложение заплатившему вам деньги клиенту, а оно откажется работать. Техническое имя этому – ад DLL. Это работает здесь: почему оно не работает там?
Лагерь Реймонда Чена полагает, что разработчикам будет проще, если создать условия, когда однажды написанный код запускается везде (хорошо, на любой Windows платформе). Лагерь журнала MSDN полагает, что разработчикам будет проще, если им дать мощные куски кода, которые можно использовать для достижения собственных целей, если они хотят заплатить за это головной болью от невероятно сложной установки, про огромную кривую обучения даже не упоминаю. Лагерь Реймонда Чена за консолидацию. Пожалуйста, не делайте хуже, пусть то, что уже создано, продолжает работать. Лагерю журнала MSDN нужна раскрутка новых гигантских кусков технологии, с которыми никто не сможет справиться. ...
>> А по моему Delphi скоро умрет. Никто здравомыслящий на Delphi не переходит. А те кто остался, рано или поздно переходят с нее на более продвинутые средства разработки приложений.
ОтветитьУдалитьПочему он должен умирать, если им активно пользуются?
>> Перешел на Visual Studio. C# куда удобнее язык чем Object Pascal.
Ну вот, ряды как грицо рядеют :(
>> Ну или тот же фотошоп, на C#. :)
ОтветитьУдалитьНу или вот Виста, один большой тормоз
> Лагерь Реймонда Чена полагает, что разработчикам будет проще, если создать условия,
ОтветитьУдалить> когда однажды написанный код запускается везде (хорошо, на любой Windows платформе).
А разве нет?
> Лагерь журнала MSDN полагает, что разработчикам будет проще,
> если им дать мощные куски кода, которые можно использовать для достижения собственных целей,
А разве нет?
Много контор могут похвастаться, что делают все с нуля и сами?
Нет, очень и очень не много.
Сто раз уже говорили, что Дельфи тем и был хорош, что позволял не особо копаясь в деталях, сконцентрироваться на конкретной задаче.
Проблема в том, что в Дельфях я лично уже начинаю тратить гораздо больше времени для решения конкретной задачи, чем для решения того же самого и с тем же результатом в .NET.
Осознав это, мы отказались от Дельфей.
А-то что Дельфи при этом дает ~ 15% прироста скорости - для бизнес-задач наплевать и растереть.
Гораздо важнее в какой срок я управлюсь.
Вот и все, собственно.
И это при том, что на Дельфях я отпахал лет так десять и писал и свои компоненты и датасеты и пр.
> если они хотят заплатить за это головной болью от невероятно сложной установки,
IMHO бред. Писали уже.
Кому-то сложно поставить .NET? ;)
Или это сложнее, чем установка Жаба-машины?
> про огромную кривую обучения даже не упоминаю.
Вообще бред.
Если вы выбрали IT специальность, то вам всю жизнь придется учиться. Не можете - выберите себе что-нибудь попроще. Табуреты колотить, например.
> Пожалуйста, не делайте хуже, пусть то, что уже создано, продолжает работать...
Это звучит как "сделайте нам качественную автовазовскую классику. Не надо нам никакого вашего новомодного автопрома с современными движками, коробками, ABS, EBD, подушками, и пр и пр. Мы в нашем "Шараже-монтаже" уже знаем все винтики в наших "ведрах" и умело их подкручиваем, а учится не хотим, да и поздно нам."
Ну что же, это тоже подход ;)
> Лагерь Реймонда Чена полагает, что разработчикам будет проще, если создать условия,
ОтветитьУдалить> когда однажды написанный код запускается везде (хорошо, на любой Windows платформе).
А разве нет?
> Лагерь журнала MSDN полагает, что разработчикам будет проще,
> если им дать мощные куски кода, которые можно использовать для достижения собственных целей,
А разве нет?
Много контор могут похвастаться, что делают все с нуля и сами?
Нет, очень и очень не много.
Сто раз уже говорили, что Дельфи тем и был хорош, что позволял не особо копаясь в деталях, сконцентрироваться на конкретной задаче.
Проблема в том, что в Дельфях я лично уже начинаю тратить гораздо больше времени для решения конкретной задачи, чем для решения того же самого и с тем же результатом в .NET.
Осознав это, мы отказались от Дельфей.
А-то что Дельфи при этом дает ~ 15% прироста скорости - для бизнес-задач наплевать и растереть.
Гораздо важнее в какой срок я управлюсь.
Вот и все, собственно.
И это при том, что на Дельфях я отпахал лет так десять и писал и свои компоненты и датасеты и пр.
> если они хотят заплатить за это головной болью от невероятно сложной установки,
IMHO бред. Писали уже.
Кому-то сложно поставить .NET? ;)
Или это сложнее, чем установка Жаба-машины?
> про огромную кривую обучения даже не упоминаю.
Вообще бред.
Если вы выбрали IT специальность, то вам всю жизнь придется учиться. Не можете - выберите себе что-нибудь попроще. Табуреты колотить, например.
> Пожалуйста, не делайте хуже, пусть то, что уже создано, продолжает работать...
Это звучит как "сделайте нам качественную автовазовскую классику. Не надо нам никакого вашего новомодного автопрома с современными движками, коробками, ABS, EBD, подушками, и пр и пр. Мы в нашем "Шараже-монтаже" уже знаем все винтики в наших "ведрах" и умело их подкручиваем, а учится не хотим, да и поздно нам."
Ну что же, это тоже подход ;)
>> Ну или тот же фотошоп, на C#. :)
ОтветитьУдалить> Ну или вот Виста, один большой тормоз
Не хотите тормозов вообще - пишите на чистом Си или C++.
При чем здесь Дельфи?
> Вот тут вы неправы, в нашей конторе до сих по используют BDE для MS SQL, при всём его неудобстве и моральной старости по сравнению с ADO и DBX+CDS,
ОтветитьУдалить> он и по скорости {гдето в 2 раза} и по использ. памяти обгоняет.
> (из за этого аргумента попытка перейти на ADO провалилась, кончилось тем что написали свой инсталлятор для BDE)
IMHO В вашем случае - это не лучший выход. ADO не очень шустрый - это точно.
Поэтому, если вам нужна скорость и все современные технологии, лучше вам бы посмотреть в сторону OLEDB. Есть сторонние компоненты для Дельфей для чистого OLEDB.
По скорости это будет сравнимо с вашим решением, а по удобству и перспективности скорее всего перекроет.
> Почему он должен умирать, если им активно пользуются?
ОтветитьУдалитьПотому что им активно уже никто не пользуется.
Найти работу на Delphi в Штатах и в Европе стало крайне проблематично.
В России им еще активно пользуются - это факт,
но также активно и не платят за него.
Delphi уже давно было пора перевести в open source. Тогда он еще пожил бы и без хозяина.
> Delphi уже давно было пора перевести в open source. Тогда он еще пожил бы и без хозяина.
ОтветитьУдалитьЧто-то Лазарусу не очень живётся без хозяина, а вообще, мой давний эротический сон - Microsoft становится владельцем Delphi :D
> Что-то Лазарусу не очень живётся без хозяина, а вообще,
ОтветитьУдалить> мой давний эротический сон - Microsoft становится владельцем Delphi :D
Не понятно только, а где эротика? :)
В лучшем случае получите еще один паскалеподобный диалект в семействе .NET
Но это уже было и не прижилось.
Дельфи - это "среда + библиотека + язык".
Оставите один язык - это уже будет не Дельфи, а Pascal.NET - вещь на большого любителя и абсолютно бессмысленная в рамках .NET.
Возможно, еще более бестолковая, чем VB.NET
Некий рейтинг популярности языков программирования на 2010 год можно посмотреть на http://itdevelop.habrahabr.ru/blog/96355/#habracut
Java вне конкуренции.
Delphi на графике на почетном последнем месте, хотя после него еще до фига не вошедших на график. Надо отдать должное, индекс Delphi чуть подрос последнее время. Видимо, благодаря D2009, D2010.
>> Лагерь Реймонда Чена полагает, что разработчикам будет проще, если создать условия,
ОтветитьУдалить>> когда однажды написанный код запускается везде (хорошо, на любой Windows платформе).
>А разве нет?
В реальности у MS это невозможно.
"однажды" - это когда вместо .NETa MS придумает новую технологию, и .NET не будет поддерживаться ))
>> Лагерь журнала MSDN полагает, что разработчикам будет проще,
>> если им дать мощные куски кода, которые можно использовать для достижения собственных целей,
>А разве нет?
50/50 Иногда их мощные куски тупо неэффективны
> ... И это при том, что на Дельфях я отпахал лет так десять и писал и свои компоненты и датасеты и пр.
Вы слишком много писали... Надо учится пользоваться чужими трудами, а не рисовать очередной велосипед. Для делфей сторонних компонентов на любой случай... по 2-3 реализации найдётся. Всё уже написано, пользуйтесь..
> В реальности у MS это невозможно.
ОтветитьУдалить> "однажды" - это когда вместо .NETa MS придумает новую технологию,
> и .NET не будет поддерживаться ))
Да что вы говорите!? ;)
Я вам по большому секрету скажу, что в будущем вообще все технологии претерпят существенные изменения.
IT-Индустрия на месте не стоит.
> 50/50 Иногда их мощные куски тупо неэффективны
Однако все продолжают пользоваться с завидным упорством ;)
О чем это говорит?
Ответ прост - у конкурентов это отношение еще хуже.
Но, вообще-то, я говорил несколько о другом.
А именно про "мощные куски кода, которые можно использовать для достижения своих целей"
Это и есть основной принцип RAD. И Дельфи из той же оперы, только вот теперь в аутсайдерах.
> Вы слишком много писали...
> Надо учится пользоваться чужими трудами, а не рисовать очередной велосипед.
> Для делфей сторонних компонентов на любой случай... по 2-3 реализации найдётся.
> Всё уже написано, пользуйтесь..
Больше всего, конечно же, улыбнула фраза "Всё уже написано, пользуйтесь.." :)
Во-первых, я приводил эти слова для того чтобы подчеркнуть, что у меня весьма внушительный опыт на Дельфи.
И что-что, а судить про Дельфи я уж точно могу.
Во-вторых, про "сторонних компонентов на любой случай" и отсутствие необходимости писать свои
- это мягко говоря не верно.
На самом деле, это тема отдельного разговора.
Но если вы так говорите, то, скорее всего, вы либо малоопытны, либо не участвовали в больших коммерческих проектах, а только во внутрикорпоративах.
А, в-третьих, я все же не мазохист, и "изобретать велосипед" для себя считаю нужным, тогда и только тогда,
когда это действительно необходимо и оправдано. Отчасти именно по этому я и пишу сейчас на C#, а не на Дельфи.
>Однако все продолжают пользоваться с завидным упорством ;)
ОтветитьУдалитьЯ незнаю, я недумаю что если прог. нужно решить 2+2 он вместо того чтобы сделать это в уме или на калькуляторе в сотовом, Он побежит в магазин купит себе мощный сервак и будет лобать програму...(аналогия)
>Во-вторых, про "сторонних компонентов на любой случай" и отсутствие необходимости писать свои
>- это мягко говоря не верно.
Вы можите привести пару примеров, чтоб в .net были решения, а у Delphi включая сторонние компоненты решение отсутствовала бы?
>Я вам по большому секрету скажу, что в будущем вообще все технологии претерпят существенные изменения.
ОтветитьУдалить>IT-Индустрия на месте не стоит.
Тем неменее написанная мною программа на Дел. в 1999, работала без проблем в свои года, продолжает работать, и я уверен что через 10 лет она будет работать в независимости от все технолог.изменений.
>будущем вообще все
Я демаю что BDE как минимум не изменится и будет стабильно работать
а я думаю что с учетом сокращения доли виндовс, передела рынка компов под планшетники и практически смертью WinMobile - песенка .Net тоже спета....
ОтветитьУдалитьУже сейчас заметны тенденции сокращения поисковых запросов по прикладным программам для обычных пользователей - а ведь это основной доход SME в IT. Зато заметен взрывной рост веб приложений написаных на PHP :))) дада... не на .Net представляете себе.... угу я это об Facebook, Twitter.... и там нафик не нужны не дельфи ни шарп....
имхо мы все в одной лодке так что не ссорьтесь.... причем изза того какой язык круче - вам платят за то что вы делаете? ну так не парьтесь
Ну мы же не обсуждаем программирование под браузер.
ОтветитьУдалитьИли Вы думайте что будущее это браузер, веб-сервисы, и мощные сервера хостеров. А обычные пользователи это лёгкие планшетники?
Я извините возможно консерватор, но я так и не нашёл применение для себя Facebook, Twitter и других новомодных разрекламированных сервисов.
К примеру, я как пользовался блокнотом и вордом для редактирования текстов так и пользуюсь, не думаю что если в интернете появится web-редактор то я буду пользоваться им...
От "Бывший Дельфист"
ОтветитьУдалить> Вы можите привести пару примеров, чтоб в .net были решения,
> а у Delphi включая сторонние компоненты решение отсутствовала бы?
"Элементарно, Ватсон". Да вы и сами это знаете:
мобильные устройства, ADO.NET, x64.
Но, основной акцент даже не в этом.
IMHO ваш вопрос, если его перефразировать, может звучат приблизительно так:
"Вы можете привести пару примеров, что мы не смогли бы срубить дерево нашими топорами, которое вы срежете вашей бензопилой?".
Ответ: "Вы срубите и топором. Вопрос лишь во времени, большем количестве необходимых вам лесорубов и приложенных вами лишних усилиях."
От "Бывший Дельфист":
ОтветитьУдалить> Тем неменее написанная мною программа на Дел. в 1999, работала без проблем в свои года,
> продолжает работать, и я уверен что через 10 лет она будет работать
> в независимости от все технолог.изменений.
И что?
Я тут как-то пару старых DOS игрушек запускал на DOS-эмуляторе.
Понастальгировал :)
Через десяток лет и вы свою программу на Win32-эмуляторе запустите и поностальгируете.
От "Бывший Дельфист":
ОтветитьУдалить> а я думаю что с учетом сокращения доли виндовс, передела рынка компов под планшетники
> и практически смертью WinMobile - песенка .Net тоже спета....
Да, да, это очень существенно! ;)
Особенно если по неумолимой статистике доля Windows составляет ~ 90%
http://netler.ru/ikt/operating-system-market-share.htm
А вообще, кто его знает, что завтра будет?
Поживем - увидим...
> Уже сейчас заметны тенденции ... PHP ...
> и там нафик не нужны не дельфи ни шарп....
Хотите быть еще востребованее - учите Жабу и/или С++
> имхо мы все в одной лодке так что не ссорьтесь.... причем изза того какой язык круче > - вам платят за то что вы делаете? ну так не парьтесь
Так-то оно так, но только мы не ссоримся а спорим. А в споре, как известно, и рождается истина ;)
>"Элементарно, Ватсон". Да вы и сами это знаете:
ОтветитьУдалитьмобильные устройства, ADO.NET, x64.
ADO.NET - это то каким боком?
>И что?
>Я тут как-то пару старых DOS игрушек запускал на >DOS-эмуляторе.
>Понастальгировал :)
Я имею виду не на эмуляторе, просто запустил и работает. Достослять ничего не надо. (в отличии от программ под .Net)
>Ответ: "Вы срубите и топором. Вопрос лишь во времени, большем количестве необходимых вам лесорубов и приложенных вами лишних усилиях."
Да вот в том то и дело что , ни по времени , ни в большем количестве работников, ваша бинзапила не обгоняет. Скорости разработки таже. У ней всеголишь удобнее кучка (И то, как выясняется, не для всех)
кучка (отпечатался) - ручка
ОтветитьУдалитьДа и не Понастальгировал - А Поиспользывал
ОтветитьУдалитьДля Понастальгировал я использую эмулятор ZX спектрума
ОтветитьУдалитьОт "Бывший Дельфист":
ОтветитьУдалить> ADO.NET - это то каким боком?
Вы знаете, ADO.NET на самом деле было оЧеПяткой.
Я хотел написать ASP.NET.
Так же можно упомянуть и все, что касаетс WEB и сервисных технологий для .NET включая и WCF и даже сопутствующий SilverLight (со 2-ой версии).
Но даже эта оговорка ( по Фрейду ) и то в кассу.
ADO.NET гораздо продуманнее стандартных дельфевых датасетов и производных от них. А отсутствие понятия DataSource и дополнительного набора DataAware компонент, значительно упрощают визуализацию сводя ее к куда более универсальному binding-у.
> Я имею виду не на эмуляторе, просто запустил и работает.
Так я и говорю - это пока.
Всего лет 15 тому назад и игрушки под DOS сами по себе работали ( без эмулятора ), и программы для Win16 еще работали.
Кстати, Misrosoft уже давно готовит очередную "подлянку" Дельфистам в виде WPF. К примеру, интерфейс самой VS2010 уже работает на WPF.
По слухам интерфейс самой Win8 уже полностью будет переписан под WPF.
А дельфисты в это время все будут ждать x64...
> Да вот в том то и дело что, ни по времени, ни в большем количестве работников,
> ваша бинзапила не обгоняет. Скорости разработки таже...
Да рубите, рубите топором на здоровье
Не так давно, сам таким же упертым был :)
>>Это гораздо проще, быстрее и читаемее, чем реализация, например, очередного наследника от TObjectList-а
ОтветитьУдалитьD2009 и выше:
var
EmployeeList: TList(Employee);
...
for Employee in EmployeeList do begin
...
==================
Знаки "больше-меньше" заменил на скобки.
Вопрос "Бывшему Дельфисту" и другим кто на C#:
ОтветитьУдалитьПереписали небольшую часть нашей системы с Del на C#. И столкнулись с проблемой нехватки памяти и как следсв. жуткие тормоза. Суть: запускается клиент (10 мег скушал сразу), загружаем структуры(объекты персонал, заказы, накладные, и др. об. пред. области) производим расчёт (500 Мег скушал), вторая итерация ещё 500 Мег, часть с первой ещё не сборщик мусора ещё освободил, на 3-й итерации происходит жопа. Кто ни будь знает как решить проблему со сборщиком мусора? В Del почти тот же алгор. , приложение не занимает более 150 Мег , т.к. освобождает сразу.
Аналогичная. проблема при автом. тестирование.: Открытие и закрытие карточек персон, доходит до N-й и жопа. Тк не успевает овободить.
Есть кто сталкивался с полобно проблемой, как решали?
От "Бывший Дельфист":
ОтветитьУдалить> Переписали небольшую часть нашей системы с Del на C#
> ...
> Аналогичная. проблема при автом. тестирование.:
> Открытие и закрытие карточек персон, доходит до N-й и жопа. Тк не успевает овободить.
> Есть кто сталкивался с полобно проблемой, как решали?
Сложно ответить однозначно. Может быть масса причин неосвобождения памяти.
Для начала неплохо бы проштудировать официальную информацию по сборщику мусора http://msdn.microsoft.com/ru-ru/library/0xy59wtx.aspx
Так же почитайте: http://msdn.microsoft.com/ru-ru/magazine/cc163491.aspx
Если вы все это знаете, то рекомендации могут быть такие:
- Попробуйте принудительный запуск GC.Collect(2)
- Проверьте не ссылается ли кто-нибудь на ваши объекты;
- Не ссылаются ли они "хитрым путем" друг на друга;
А проще поставьте .NET Memory Profiler и он вам покажет в чем ваша проблема.
Главное понять, что Gabage Collector не избавляет от всех проблем с освобождением памяти и нужно достаточно хорошо знать устройство управляемой кучи в .NET чтобы писать серьезные приложения.
От "Бывший Дельфист":
ОтветитьУдалить>D2009 и выше:
>var
>EmployeeList: TList(Employee);
>...
>for Employee in EmployeeList do begin
"Плавали - знаем"
Уже здесь писалось, дженерики в D2009-D2010 слегка кастрированные и неудобные по сравнению с C#. Например, из за отсутствия методов Find, Exist и пр. работающих с "предикатами".
НО ВООБЩЕ-ТО ВЫ НЕ СОВСЕМ В ТЕМУ
В том посте писалось не про сами дженерики, а про удобство работы с "LINQ to Objects" совместно с дженериками. А LINQ, как известно, в Дельфи пока не пахнет.
От "Бывший Дельфист":
ОтветитьУдалитьПЫ.СЫ.
Кстати, еще про убогость реализации дженериков в Дельфях.
Для Дельфевых дженериков нельзя создавать методы расширения ( в последних версиях Дельфей это называется Class Helpers ).
А это явная недоработка. Поскольку, например, весь LINQ написан посредством методов рассширения. Да и те же Find, Exist с предикатами можно бы было просто реализовать путем расширения базового TList(T).
Пока видно, что Embarcadero дерет с MS новые наработки с большим опозданием и неумело.
RAD Studio XE.
ОтветитьУдалить"Бывший Дельфист" должен обрадоваться). В RAD Studio XE нет ни 64бит ни cross-compiler для Mac и Lin.
(((
От "Бывший Дельфист":
ОтветитьУдалить> "Бывший Дельфист" должен обрадоваться).
> В RAD Studio XE нет ни 64бит ни cross-compiler для Mac и Lin.
Я посмотрел рекламный ролик на сайте Embarcadero, два толстяка убеждают друг друга как им теперь будет офигенно работать, когда в IDE наконец-то добавили поддержку Subversion.
Ну надо же!!!
К слову, для VS также можно установить бесплатный продукт AnkhSVN для поддержки Subversion так же бесшовно интегрирующийся в оболочку.
Короче, слов нет, одни буквы (
Только я не радуюсь.
Если в результате на рынке RAD для Win вскоре останется одна MS и полное отсутствие альтернативы - плохо будет всем.
Да парни действительно толстые, по идеи ещё должен быть и 3-й толстяк. Ну что же новый завтрак они пообещали, я так понял, в след 3 версиях (если 1 проект = 1 версии = 1 год).
ОтветитьУдалитьНу движение всё таки есть, Призм под послед .Net, новый PHP, + много мелочей повыш. качество.
Намёк одного толстяка, что что этими инструм. можно построить серьёзную систему, не имея 64бит и крос-пл. компилят., например 3-х зв. : 1-зв СУБД (крос-пл) -> 2-зв Сер.Прил на PHP (крос-пл) -> 3-зв Клиент Del.w32
(полная альтернатива MS и .Нет)
---------------------
ОтветитьУдалить1-зв СУБД (крос-пл) -> 2-зв Сер.Прил на PHP (крос-пл) -> 3-зв Клиент Del.w32
(полная альтернатива MS и .Нет)
---------------------
Убогая альтернативка :(
В новом наборе программ от Adobe версии CS5 уже нет 32-х битных версий программ обработки видео.
ОтветитьУдалитьAdobe Premiere и Adobe After Effects теперь поставляются только в 64-х битном варианте.
Это уже серьезный сигнал для IT-индустрии, однако.
А в Delphi 64-бит не будет еще годик судя по всему, а соответственно проекты будут переведены не раньше чем года через 2-3...
Вы все еще кипятите на Delphi? ;)
Сегодня был на конференции. Один из толстяков, Девид И (Кстати он не такой уж и толстый, похудел слегка), в первые 20 мин удивил публику. Он открыл Мак, и запустил там демо проект Рыбы (из стандартной поставки делфи) скомпиленные под QT Mac. Далее он запустил консольное 64 разрядное приложение где зарезервировал а потом освободил 5Гиг. памяти. Это оказались бета коппиляторы. Итого x64 уже выдит зимой. VCL кросплатф. в след. версии. Над этими задачами трудятся 2 команды раработчиков.
ОтветитьУдалитьТакже было показан новый ДатаСнап. К серверу можно конектится Десфи кл., С++ кл., .Nen кл., Моno кл., HTML(через джава скрипт), IPod кл.(Mac) - Впечатлило. Также были продемонстрированы Колбеки - Сильно впечатлило.
Далее показалновый PHP - Выглядит солидно. И программирование для IPod - Инопланетянская среда).
Ну были ещё всякие итересные моменты Работа с SVN, С Майкрософтовскими облаками через ДатаСнап, какойто замут с ФайсБуком на PHP...
Во второй части 'толстый' уехал. И наш(русскоязычный) коллега рассказал про средства для работы с БД. - Впечатлило, Майкрософтовский МанеджментСтудио показался 'унылым говном'.
Вообщем впечатления остались хорошие. Если они будут продолжать в этом духе (и понизят цены), MS со своими 'крутыми' технологиями уйдёт далеко в анал.
>Вы все еще кипятите на Delphi? ;)
ОтветитьУдалитьДа, и думаю что ещё долго будем.
Да, сигнал дейтвительно серьёзный!
Adobe Premiere и Adobe After Effects - а как Вы думайте они на .Net написаны?
>>Описался, не IPod а IFon
ОтветитьУдалитьОпять описался IPhone :)
Требуется Debugger Engineer
ОтветитьУдалитьEmbarcadero Technologies Inc.,
от 70 000 до 90 000 руб.
Санкт-Петербург
Join the RAD Studio development team, working on Embarcadero’s debugger functionality for Delphi and C++Builder to meet business requirements. You will be responsible for developing and maintaining debugger technologies for multiple platforms, including Windows, OS X and Linux.
http://hh.ru/vacancy/3336030?query=Delphi
ОтветитьУдалить>> Вы все еще кипятите на Delphi? ;)
ОтветитьУдалить> Да, и думаю что ещё долго будем.
Флаг в руки, барабан на шею :)
> Да, сигнал дейтвительно серьёзный!
> Adobe Premiere и Adobe After Effects
> - а как Вы думайте они на .Net написаны?
На С++ они написаны и для x64 откомпилированы.
На нылых и плохо-оптимизирующих Паскалях, и в управляемых средах .Net/Java такие серьезные "CPU & Memory eating" приложения, как правило, не пишут.
Имелся в виду начавшийся переход на 64-бит от гигантов софт индустрии ( таких как Adobe ). Причем, уже безальтернативный. 32-х битных версий Premiere CS5 и After Effects CS5 просто нет.
> Вообщем впечатления остались хорошие.
ОтветитьУдалить> Если они будут продолжать в этом духе (и понизят цены),
> MS со своими 'крутыми' технологиями уйдёт далеко в анал.
Свежо питание, да серится с трудом :)
А пока в сухом остатке видны одни только "если".
По факту же им пока далеко до MS по технологичности, функционалу, удобству и пр.
Кстати, тот же ДатаСнап - это детский сад по сравнению с куда более продвинутым и универсальным WCF от MS.
> Требуется Debugger Engineer
ОтветитьУдалить> Embarcadero Technologies Inc.,
> от 70 000 до 90 000 руб.
> Санкт-Петербург
Деньги для Питера не такие уж большие для такого уровня специалиста.
Учитывая, что с них еще снимут 13%.
К тому же, это же сама Embarcadero!
А среднестатистический дельфист получает меньше.
> Кстати, тот же ДатаСнап - это детский сад по сравнению с куда более продвинутым и универсальным WCF от MS.
ОтветитьУдалитьНу а по производительности этих 2-х технологий, кто нибудь что может сказать?
> Ну а по производительности этих 2-х технологий, кто нибудь что может сказать?
ОтветитьУдалитьПроизводительность в лоб сравнить не просто.
Да и в чем мерить? В скорости передачи данных?
Тогда смею предположить, что у MS при использовании NetTcpBinding она будет ~ такая же, а при локальной связи по NwtNamedPipeBinding даже быстрее.
Другое дело, что WCF от MS - это все же более всеобъемлющая и удобная технология, чем DataSnap. У Embarcadero нет пока таких средств, чтобы ваять подобное.
> Кстати, тот же ДатаСнап - это детский сад по сравнению с куда более продвинутым и универсальным WCF от MS.
ОтветитьУдалить>Другое дело, что WCF от MS - это все же более всеобъемлющая и удобная технология, чем DataSnap. У Embarcadero нет пока таких средств, чтобы ваять подобное.
Аргументы?
Я тоже могу много чего предпологать...
> Да и в чем мерить?
В скорости получения выборок различного размера (10МБ, 100МБ, ...)на тонкого клиента через серв. приложений. (на одном железе)
> .. и удобная технология, ..
И как вы это определили?
Давайте я тоже снесу свои 5 копеек.
ОтветитьУдалитьЕсли без субъективного мнения, то у меня дела обстоят так: программирую на Delphi профессионально. В нашей конторе очень много накопилось софта на нем, поддержка и развитие не предусматривают переход. Delphi XE официально купленный. Я Delphi не люблю, но контору менять пока не собираюсь.
Современная Delphi IDE больна прост-таки детскими болезнями. При компиляции большого числа проектов вылетает с out of memory (но уже 2011 год на дворе, сборщик мусора все-таки придуман). Нет поддержки новых фич (да и некоторых старых) в ими же придуманном синтаксисе. Так и живем, в окне Structure висит куча Error-ов, но код компилится. При Ctrl+click частенько идет переход не туда, куда нужно.
В отличие от С++, выбора полноценного IDE программист на Delphi лишен.
При переходе на новую версию Дельфей каждый раз начинается свистопляска с компонентами. Сравните с интероперабельностью .NET.
Уже 2011 г, 64-х битные процы вовсю шагают по планете, но официального компилятора под них до сих пор нет. При том что наши приложения вполне могуть есть очень много памяти, я сам сталкивался с проблемой порога в 2 гига на процесс.
Если говорить субъективно - синтаксис языка просто чудовищен. Попробовав на зуб такие языки, как C#, F#, Boo - могу говорить об этом со всей ответственностью.
Я ненавижу компанию Embarcadero за то, что она занимается гальванизацией этого трупа. Без этих ее усилий мы мы потихоньку начали миграцию на что-нть более приличное, а так...
Вот ещё оно субъективное мнение
ОтветитьУдалить> ...сборщик мусора ...
Невно наткнуляс на интересные тесты, сравнения .NET и нативом
Автоматическое управление памятью в .NET
http://rsdn.ru/article/dotnet/GCnet.xml
Интересны графики (3 шт) зависимости производительности от кол. объектов(оперируемой памяти)
Аналогичные (правда поверхностные) тесты я проводил сравнивая Delphi
Какие выводы я сделал для себя:
1) .NET не может быть использован для крупных приложений (которые используют большое кол. объектов и данных),
2) Маленькое приложение работающее эффективно .NET, в процессе развития рано или поздно дойдёт до точки когда потеря производительности будет слишком значима чтобы, её сопоставлять с удобством транслируемого языка, и среды разработки.
И для разраб. БД интересный тест:
Сравнение скорости доступа к данным (ADO.NET, ADO, ascDB)
http://rsdn.ru/?/article/db/DBSpeed.xml
жаль что только с технологиями от MS, с выводами автора я согласен
> ... 64-х битные процы ...
Рано или поздно x64 появится в Delphi, и что? что-то сильно изменится. Для 5 человек из 100, возможно. Остальным это как 6 палец на ноге, только мысль о светлом будущем))
> ... В нашей конторе ...
В нашей конторе (довольно крупной), частично перешли на нескольких продуктов. Мнения правда разделились по поводу светлого будущего. Но один факт остался общим, при "одинаковых задачах" кода на C# нужно писать больше чем на Delphi
Анонимный >>> ******************************************
ОтветитьУдалитьhttp://rsdn.ru/article/dotnet/GCnet.xml
Интересны графики (3 шт) зависимости производительности от кол. объектов(оперируемой памяти)
Аналогичные (правда поверхностные) тесты я проводил сравнивая Delphi
Какие выводы я сделал для себя:
1) .NET не может быть использован для крупных приложений (которые используют большое кол. объектов и данных),
2) Маленькое приложение работающее эффективно .NET, в процессе развития рано или поздно дойдёт до точки когда потеря производительности будет слишком значима чтобы, её сопоставлять с удобством транслируемого языка, и среды разработки.
>>> ********************************************
Примеры приведенные по вашей ссылке не показательны.
Накручивать выделение по несколько сотен байт на пустом месте без остановки ( без передышки ) несколько десятков миллионов раз?!
А смысл?!
Нет, теоретически, конечно, можно представить себе любую задачу, но практически сомневаюсь, что вы часто сталкиваетесь с подобным.
Сам же по себе тест достаточно абсурден, о чем даже пишут сами авторы.
В крупных же прикладных приложениях из разряда "интерфейсно-БД-учетных" ( то есть там, где раньше Дельфина и использовалась в основном ) времени у GS очистить все в параллельном потоке всегда будет более чем предостаточно.
Так что никакой существенной потери производительности и в больших проектах вы не ощутите. А вот работать с большими проектами на С# все же удобнее, как ни крути.
Скорее уж как раз таки Дельфи сейчас для мелких или специализированных проектов больше подходит. Опять же фрэимворк тащить не нужно для какой-нибудь программы-контроллера.
( Программист со стажем на С++, Дельфи и С# )
>Накручивать выделение по несколько сотен байт на пустом месте без остановки ( без передышки ) несколько десятков миллионов раз?!
ОтветитьУдалитьНу а как Вам код, который читает с БД инфу и на каждую запись создает объект, после некой обработки... Разве это не тот же вариант, который часто используется на практике...??
Единственное меня очень сильно смущает (в статье), что по идеи при такой загрузки после 500Мег (из статьи) производительность ляжет, тогда плюсы 64б. архитектуры (которая позволяет использовать > 2гигов) никогда не будут достигнуты...
ОтветитьУдалитьНо тесты здравые по крайне мери их грамотный чел. делал.
> ...сборщик мусора ...
ОтветитьУдалить> Невно наткнуляс на интересные тесты,
сравнения .NET и нативом
Друг мой, а почему сразу дотнет? Сборщик мусора, насколько я знаю, впервые появился в Яве (может я конечно и ошибаюсь). Кроме дотнета он имеется также в D и еще много где. ЛЮБОЙ высокоуровневый язык (Python к примеру) обязательно имеет сборщик мусора.
Но речь-то была о другом. Если ты не умеешь грамотно работать с памятью - GC тебе в помощь. Программеры из Embarcadero, судя по Out of memory при компиляции большого числа проектов из IDE, не умеют.
> ... 64-х битные процы ...
> Рано или поздно x64 появится в Delphi, и что?
Поздно. Очень поздно, непозволительно поздно. Настолько, что люди уже расчухали, что Delphi сурово отстал.
> при "одинаковых задачах" кода на C# нужно писать больше чем на Delphi
Странный у вас какой-то C#.
> ...сборщик мусора ...
ОтветитьУдалить> Невно наткнуляс на интересные тесты,
сравнения .NET и нативом
Друг мой, а почему сразу дотнет? Сборщик мусора, насколько я знаю, впервые появился в Яве (может я конечно и ошибаюсь). Кроме дотнета он имеется также в D и еще много где. ЛЮБОЙ высокоуровневый язык (Python к примеру) обязательно имеет сборщик мусора.
Но речь-то была о другом. Если ты не умеешь грамотно работать с памятью - GC тебе в помощь. Программеры из Embarcadero, судя по Out of memory при компиляции большого числа проектов из IDE, не умеют.
> ... 64-х битные процы ...
> Рано или поздно x64 появится в Delphi, и что?
Поздно. Очень поздно, непозволительно поздно. Настолько, что люди уже расчухали, что Delphi сурово отстал.
> при "одинаковых задачах" кода на C# нужно писать больше чем на Delphi
Странный у вас какой-то C#.
>Программеры из Embarcadero, судя по Out of memory при компиляции большого числа проектов из IDE, не умеют.
ОтветитьУдалитьСудя по ошибки у вас D2006, скаченный с торентов))
Я чегото сомневаюсь что у вас там проектов >2Гиг
> Судя по ошибки у вас D2006, скаченный с торентов))
ОтветитьУдалитьНу что за детский сад! Сказал же: XE, купленный.
> проектов >2Гиг
Выражение супер. выдает квалификацию (вернее, ее отсутствие) с головой.
Анонимный >>> ******************************************
ОтветитьУдалитьНу а как Вам код, который читает с БД инфу и на каждую запись создает объект, после некой обработки... Разве это не тот же вариант, который часто используется на практике...??
>>> ********************************************
Миллионны раз без остановки читает инфу из БД и на каждую запись создает объект в памяти?!!!
Где у вас такая практика?
Я бы такого программиста выпорол бы. Тут и на Дельфи тормоза начнутся.
Нормальная практика - совершать всю возможную обработку с большим числом данных непосредственно на сервере.
На клиента же вы тянете только необходимое в данную секунду.
Один документ, например или "окно" из N-го количества однотипных записей для отображения в гриде на экране.
Тащить миллионы записей одновременно на клиента - ЭТО ОЧЕНЬ И ОЧЕНЬ ПЛОХАЯ ПРАКТИКА без относительно языка или архитектуры.
Таких программистов гнать надо в зашей.
Анонимный >>> ******************************************
ОтветитьУдалитьПоздно. Очень поздно, непозволительно поздно. Настолько, что люди уже расчухали, что Delphi сурово отстал.
>>> ********************************************
Подверждаю, Дельфина отстала. Местами даже очень существенно в идеологическом и технологическом плане.
Но у Дельфины все равно остаются козыри в кармане. Как ни крути найтивная компиляция в один EXE-шник - это есть хорошо.
Чего бы там не звездели про быструю JIT компиляцию на .NET. По факту же большой проект может существенно притормаживать на загрузке, если ему только не делать найтивный образ NGEN-ом ( но и с NGEN-ом тоже не все так просто )
Дельфина более подходит для написания проектов, с более или менее адекватным временем отклика ( когда это важно ). Т.е. всякие там контроллеры и программы обслуживающие разную аппаратуру я бы не C# писать бы все же поостерегся.
К тому же виснет студия при отладке многопоточных С# приложений частенько ( что VS2008, что VS2010 ).
Да и MS сама честно предупреждает, что C# не стоит использовать в критичных по времени отклика приложениях.
В таких случаях они предлагают пользоваться старым добрым С++, но мы то с вами понимаем, к какому геморою это зачастую приводит ( в сравнении с Дельфи ).
Зато морды для БД, и прочую интерфейсную часть на C# писать ГОРАЗДО удобнее, чем на Дельфине. Это да.
Анонимный >>> ******************************************
ОтветитьУдалитьСудя по ошибки у вас D2006, скаченный с торентов))
Я чегото сомневаюсь что у вас там проектов >2Гиг
>>> ******************************************
Не, это точно, что последние версии Дельфины порой валятся с идиотскими ошибками.
Например, у нас есть серьезный и большой проект на Дельфи ( контроллер спец.аппаратуры ) и на нем время от времени проявляются все эти ошибки.
Самая безобидная - нежелание переходить по ссылке ( ctrl+click). Лечится закрытием о открытием проекта в IDE.
Надоедливая - сумашедшее моргание контекстной подсказки. Лечится тем же.
Более серьезная - вывод ошибки о circular reference при компиляции там где ее реально нет.
Но проект большой и взаимное проникновение юнитов все же присутствует ( в разумных пределах ).
Лечится полным построением ( Build ) а не частичной компиляцией.
Еще более серьезные - после некоторого времени работы могут появляться внутренние ошибки или падение IDE с выводом идиотских ошибок.
Лечится перезагрузкой IDE.
Дельфи 2010 купленная и все апдейты установлены.
Анонимный >>> ******************************************
ОтветитьУдалитьПоздно. Очень поздно, непозволительно поздно. Настолько, что люди уже расчухали, что Delphi сурово отстал.
>>> ********************************************
Да, еще в догонку о реальных козырях Дельфи и найтивной компиляции:
Вашу великую .NET программу любой школьник может перевести в исходный код при помощи .NET Reflector
-> защита коммерческих проектов на C# весьма проблематична.
И только не надо мне рассказывать про Dotfuscator.
Во-первых, по тому, что при использовании Dotfuscator-а вы лишаетесь возможности нормального трэйсинга собственного приложения у клиента. А это очень плохо! Поскольку, я ни разу не верю, что кто-то пишет вообще без ошибок :)
Во-вторых, dotfuscator может и запутает логику, но в конечном счете не предотвратит относительно легкое нахождение места, где вы ограничиваете своего клиента количеством соединений или триал-дней.
В отличии от этого полноценный EXE-шник дебажить куда сложнее. Тем более при наличии в нем "хитрых запуток". Здесь уже для вскрытия вашей "дойной коровы" школьником зачастую не обойтись.
Поэтому, C# и .NET конечно великая вещь и запросто вытеснит Дельфину из всех "внутрекорпоративов", "мордо-писных" и тем более WEB проектов.
Но в коробочном секторе .NET - это все же не комильфо.
Вот если бы MS сделала бы нормальный оптимизирующий найтивный линкер, линкующий все в один найтивный EXE-шник - ВОТ ЭТО БЫЛО БЫ ДЕЛО!!!
( Кстати, был такой сторонний проект, но благополучно заглох по понятным причинам.)
А покуда это не так, программисты на С++, Delphi и прочем найтиве будут востребованы еще очень долго.
Анонимный >>> ******************************************
ОтветитьУдалитьМиллионны раз без остановки читает инфу из БД и на каждую запись создает объект в памяти?!!!
Где у вас такая практика?
Я бы такого программиста выпорол бы. Тут и на Дельфи тормоза начнутся.
Нормальная практика - совершать всю возможную обработку с большим числом данных непосредственно на сервере.
На клиента же вы тянете только необходимое в данную секунду.
Один документ, например или "окно" из N-го количества однотипных записей для отображения в гриде на экране.
Тащить миллионы записей одновременно на клиента - ЭТО ОЧЕНЬ И ОЧЕНЬ ПЛОХАЯ ПРАКТИКА без относительно языка или архитектуры.
Таких программистов гнать надо в зашей.
>>> ********************************************
Дорой друг, Вам, с такими доводами и практиками в детсаде надо работать воспитателем – порщиком.
Есть же и другие архитектуры:
1) Где на БД по различным причинам (безопасности, производительности, ...) не создаются ХП(используют только как хранилища).
2) Где 3,4 звенка, и есть сервер приложений.
3) Где нет СУБД вообще., использ. файловые хранилища, либо веб-службы.
4) Или СУБД много и они гетерогенны и не имеют доступа к друг другу.
И во всех этих вариантах архитектур, вы собирайтесь "сосать" с дотнетом?
---
Я думаю что для написания "морд" не обязательно пользоваться высокоуров. языками, попробуйте ОраклФормс посмотреть или подобные конструкторы.
Анонимный >>> ******************************************
ОтветитьУдалитьДорой друг, Вам, с такими доводами и практиками в детсаде надо работать воспитателем – порщиком.
Есть же и другие архитектуры:
1) Где на БД по различным причинам (безопасности, производительности, ...) не создаются ХП(используют только как хранилища).
2) Где 3,4 звенка, и есть сервер приложений.
3) Где нет СУБД вообще., использ. файловые хранилища, либо веб-службы.
4) Или СУБД много и они гетерогенны и не имеют доступа к друг другу.
********************************************
По пунктам:
1) Для того чтобы реализовать большую часть обработки на сервере порой вовсе не нужно писать ХП. Например, можно обойтись последовательностью запросов и временными таблицами на сервере же. Надеюсь, это для вас это не секрет.
2) Нормально спроектированная 3-х звенка ничем в этом плане не отличается от вышеуказанного. Она также должна обрабатывать и хранить большую часть на сервере, а на клиента одновременно высылать, лишь небольшую порцию, например, уже преобразованных бизнес-данных, ну или порционно те же дата-сеты.
3) При чем здесь файл-хранилища?
Вы что весь файл в несколько гигов в память сразу грузите и на мелкие объекты его сразу разбиваете?
Если да, то вас действительно нужно пороть :)
А при чем здесь веб-службы, я вообще не понял.
Вы это для пущего веса что-ли сказали? ;)
Веб служба это по сути просто форма организации доступа к любым типам данных через XML.
Ну при чем здесь несколько миллионов создаваемых одновременно мелких объектов?
4) ???? Сами-то поняли к чему вы это сказали?
Вы что качаете миллионы записей в память из разных баз, преобразуете их в объекты и в памяти делаете безиндексный поиск, связку, или выборку по этим объектам?
УжОс-то какой!
Если да, то пороть для ума и немедленно! :)
Анонимный >>> ******************************************
И во всех этих вариантах архитектур, вы собирайтесь "сосать" с дотнетом?
>>> ********************************************
Я ответил, на абсурдность приведенных вами вариантов.
Хотя, все вышеперечисленные методы и подходы ( если только по уму ) вы абсолютно с таким же успехом можете забацать и на .NET, но при этом с гораздо большим удобством, чем на Дельфях. В этом-то, собственно, и фишка C#+.NET, которая всех в конечном счете и подкупает.
Так что не гоните пурги.
.NET будет нервно курить в стороне практически только в одном случае, а именно когда время отклика может быть весьма и весьма критично.
Т.е., когда есть разница между ( условно ) 10мс и 50мс в ответе на прерывание.
Но таких задач весьма не много.
Анонимный >>> ******************************************
Я думаю что для написания "морд" не обязательно пользоваться высокоуров. языками, попробуйте ОраклФормс посмотреть или подобные конструкторы.
>>> ********************************************
Даже многие партнеры Oracle и то уже слезли с ОраклФормс, поскольку это более громоздко, гораздо менее функционально, и менее быстро. Например, в Питере крупнейший поставщик решений от Oracle ( Leaves ) и тот уже морды на C# давно пишет.
> И во всех этих вариантах архитектур, вы собирайтесь "сосать" с дотнетом?
ОтветитьУдалитьПохоже, что дот-нет и его реальные возможности вы не знаете.
Даже в многозвенках и тем более в веб сервисах Дельфина отстала капитально.
Учи матчасть - WCF.
>По пунктам:....
ОтветитьУдалитьПолная хуйня.
Боюсь, с вашим пониманием архитектур(С# интерфес - CУБД - рабочая лошадка), вам позно что либо понимать.
>.NET будет нервно курить в стороне практически только в одном случае, а именно когда время отклика может быть весьма и весьма критично.
Т.е., когда есть разница между ( условно ) 10мс и 50мс в ответе на прерывание.
Но таких задач весьма не много.
У нас девексовский ком. выбор даты поставил рекорд 3000мс каледарь открывался (за это время нативный DBX успевает засосать с сервока 100 000 записей, ~250МБ), и представляете .NET не курит в стороне в тек. задаче это приемлемо))
>Учи матчасть - WCF.
Вы меня не поняли , сейчас любая технология сможет скачать данный с веб-службы, вопрос только в объёме и скорости.
>Боюсь, с вашим пониманием архитектур(С# интерфес - CУБД - рабочая лошадка)
ОтветитьУдалитьЯ поправлю, у меня нет возможности с каждым приложением придавать в комплекте(орокловый сервак и мощную машину с админом). Я не так крут как парни из питера.
Анонимный >>> *****************************************
ОтветитьУдалитьПолная хуйня.
Боюсь, с вашим пониманием архитектур(С# интерфес - CУБД - рабочая лошадка), вам позно что либо понимать.
>>> ********************************************
Ну что же, понятно и, главное, что аргументированно :)
- "Полная хуйня!" и все тут.
- А мы как закачивали все данные на клиента так и будем работать по схеме фаил-сервер или на еще каком другом изобретенном нами "велосипеде".
Честно, говоря очень бы интересно было посмотреть на ваши поделки, где сервер используется лишь как хранилище и вся обработка на клиенте.
Так, что называется, чистА поржать :)
Анонимный >>> *****************************************
Т.е., когда есть разница между ( условно ) 10мс и 50мс в ответе на прерывание.
Но таких задач весьма не много.
>>> ********************************************
Думаю, вы не имеете дело такими задачами.
99% прикладных, учетных, офисных, внутрикорпоративных, и даже enterprise класса к таким задачам не относятся.
Если же вы хотите оценить реальную разницу в скорости конечного машинного кода ( Delphi vs .NET ), то вот вам небольшой вычислительный тест ( Вычисление числа Пи до 10000 знаков )
Исходники:
http://rapidshare.com/files/456439304/Pi_Competition.rar
На моем Core2Quad результаты такие:
Delphi: 3640ms
C#: 3970ms
Итого у Delphi конечный код быстрее на ~ 8%
Много это или мало решать вам.
На мой взгляд это вообще ни о чем в рамках учетных и прикладных задач, где больше времени тупит сам пользователь.
К слову, аналогичный алгоритм для Intel C++ компилятора дает прирост на ~ 20%. Так что для Real-Time решений тогда лучше уж выбирать хороший C++ компилятор, а не Дельфину.
Анонимный >>> *****************************************
Я поправлю, у меня нет возможности с каждым приложением придавать в комплекте(орокловый сервак и мощную машину с админом). Я не так крут как парни из питера.
>>> ********************************************
??!! Причем здесь крутость этих парней?
Вы просто заикнулись про OracleForms. На что я вам ответил, что эту приблуду даже явные ораклисты уже сменили на C#.
И крутость здесь вовсе не причем. Почти любой сервер сейчас сопрягается с .NET с таким же успехом как и с Delphi.
>Ну что же, понятно и, главное, что аргументированно :)
ОтветитьУдалитьНу а какие тут могут быть аргументы. Извините за грубую аналогию: Вас просят взять такси до Домодедово, в нуж. время чтоб успеть на самолет на Красноярск, Вы берете автобус до Красноярска, в 3раза дороже, аргументируя это тем что, Вам же туда же, это ни чем не отличается, даже круче.
Ещё я вам секрет открою, в файлах могут хранится не только программы, документы, порно фильмы (с поркой), картинки, ..., но и данные которые можно обрабатывать. И Веб-служба может дать данные, которые тоже можно обработать, даже не запихивая в СУБД.
>чистА поржать :)
Смотрите свой код и на результат его работы, я предполагаю у Вас найдутся "смешные" моменты
>Вычисление числа Пи... ~ 8%
Ахуенный тест. Жалко что он только для числа пи так работает. В реальных приложениях, пользователи(заказчики) просто гавном исходят когда у них откики 500Мс - 3000Мс. Или когда приложение "захлёбывается"
В вышеприведённых комментариях есть опечатки.
ОтветитьУдалить"Полная хуйня." следует читать как "Вздор."
"Ахуенный тест" следует читать как "Этот тест здесь неуместен".
А вообще, прошу воздержаться от использования мата. В противном случае, начну удалять комментарии.
С уважением.
Анонимный >>> *****************************************
ОтветитьУдалитьНу а какие тут могут быть аргументы. Извините за грубую аналогию: Вас просят взять такси до Домодедово, в нуж. время чтоб успеть на самолет на Красноярск, Вы берете автобус до Красноярска, в 3раза дороже, аргументируя это тем что, Вам же туда же, это ни чем не отличается, даже круче.
>>> ********************************************
Давайте по порядку.
Вы говорили, у вас "нет возможности с каждым приложением придавать в комплекте(орокловый сервак и мощную машину с админом)"
Спрашивается, а зачем вам вообще Оракл?
Вы знаете, что есть куча других SQL-серверов не требующих ни платы, ни мощных машин, ни админов.
Существуют встроенные и прилинкованные SQL- серверные решения.
Даже у Оракла и у MSSQL есть бесплатные lite версии, мощности которых для небольших задач хватает с большим запасом.
ЗАЧЕМ ИЗОБРЕТАТЬ СВОЙ ВЕЛОСИПЕД И ТРАТИТЬ НА ЭТО ДРАГОЦЕННОЕ ВРЕМЯ?
Анонимный >>> *****************************************
Ещё я вам секрет открою, в файлах могут хранится не только программы, документы, порно фильмы (с поркой), картинки, ..., но и данные которые можно обрабатывать. И Веб-служба может дать данные, которые тоже можно обработать, даже не запихивая в СУБД.
>>> ********************************************
Вы предпочитаете порнофильмы с поркой, что ли? :D
Ну хорошо, забудем про БД в данной задаче.
В вашем файле будет храниться произвольный поток данных. Чем здесь тогда Дельфина круче .NET?
.NET работает с потоками ровно также как и Дельфина.
При чем здесь одновременное создание и удаление миллионов объектов?
Анонимный >>> *****************************************
Аху... тест. Жалко что он только для числа пи так работает. В реальных приложениях, пользователи(заказчики) просто гавном исходят когда у них откики 500Мс - 3000Мс. Или когда приложение "захлёбывается"
>>> ********************************************
Во-первых, вы не правы.
Это очень показательный тест, который демонстрирует то, что качество машинного кода, получаемого на выходе после компиляции из .NET байт-кода очень и очень хорошее и вполне сравнимо с найтивными компиляторами.
Во-вторых, я привожу реальные тесты с исходниками. Которые каждый может проверить.
Вы же мне рассказываете бездоказательные сказки про каких-то заказчиков, которые просто "гОвном исходят" ( пишется через "О" ), при разнице 0,5c - 3c.
А тогда можно предположить, что, возможно, у кого-то просто руки не от туда растут? ;)
Вы конкретный пример пришлите, тогда и поговорим.
Анонимный >>> *****************************************
ОтветитьУдалитьНу а какие тут могут быть аргументы. Извините за грубую аналогию: Вас просят взять такси до Домодедово, в нуж. время чтоб успеть на самолет на Красноярск, Вы берете автобус до Красноярска, в 3раза дороже, аргументируя это тем что, Вам же туда же, это ни чем не отличается, даже круче.
>>> ********************************************
Причем здесь "круче"/"не круче" вообще?
Давайте по порядку.
Вы сказали:
"у меня нет возможности с каждым приложением придавать в комплекте(орокловый сервак и мощную машину с админом)."
Для начала, почему вы уперлись в Оракл?
Существует куча беплатных SQL-серверов ( в том числе и встраиваемые решения ), которые не требуют ни мощной машины ни админа.
Кроме того, почти у всех коммерческих серверов есть бесплатные lite версии, так же годами работающие без админов на простеньких машинах.
СПРАШИВАЕТСЯ, ЗАЧЕМ ИЗОБРЕТАТЬ СВОЙ ВЕЛОСИПЕД?
Тем более для небольшого заказа.
Анонимный >>> *****************************************
Ещё я вам секрет открою, в файлах могут хранится не только программы,...даже не запихивая в СУБД.
>>> ********************************************
А здесь в чем здесь разница между Дельфиной и C#. С потоковыми данными ( файлами ) они работают одинаково.
При чем здесь необходимость одновременно создавать и удалять миллионы объектов?
Анонимный >>> *****************************************
("Этот тест здесь неуместен" :)
Жалко что он только для числа пи так работает. В реальных приложениях, пользователи(заказчики) просто .... исходят когда у них откики 500Мс - 3000Мс. Или когда приложение "захлёбывается"
>>> ********************************************
Во-первых, этот тест как раз очень и очень показателен. Поскольку, он показывает, что качество конечного машинного кода, генерируемого .NET. очень высокое и сравнимо с найтивными компиляторами.
Во-вторых, я привожу реальные примеры с исходниками, а не голословные заявления, что какой-то там заказчик недоволен скоростью какой-то работы.
Это не аргумент, потому как это может быть всего лишь следствием неумения пользоваться определенными инструментами.
И я нигде не говорил, что C# "круче". Я говорил свое мнение, что для огромного числа задач ( но не для всех ) C#+.NET удобнее Дельфины.
>В вышеприведённых комментариях есть опечатки. ...
ОтветитьУдалитьНу зря Вы так. Некая Дискриминация русского языка получается.
Причем здесь "круче"/"не круче" вообще?
ОтветитьУдалитьЯ под "круче" понимаю быстрее и мощнее, т.е за одно и тоже время обработает больше информации.
>Для начала, почему вы уперлись в Оракл?
Оракл + Не виндов.серв. + хорошее железо = решение которому сейчас врятле найдется конкурент.(Жалко что очень дорого)
>Существует куча беплатных SQL-серверов ( в том числе и встраиваемые решения ), которые не требуют ни мощной машины ни админа.
К сожалению я знаю только одно достойное решение - FB, все остальное пока не натом уровне. (MySQL - считаю платным)
>Кроме того, почти у всех коммерческих серверов есть бесплатные lite версии, так же годами работающие без админов на простеньких машинах.
Об этом много интересных постов написано и во всех фигурирует одно название "Бесплатный сыр в мышеловке"
>СПРАШИВАЕТСЯ, ЗАЧЕМ ИЗОБРЕТАТЬ СВОЙ ВЕЛОСИПЕД?
Тут не совсем-то о велосипеде речь идёт. Вот из всех СУБД с которыми я сталкивался в работе (Оракл, MSSQL, FB) для обр. данных ХП испол. врем. или пост. таблицы которые физически находятся на HDD. И тут я боюсь сравнивать обработку на Delphi (или C#) (используя колек. объектов или ClientDataSet которые физически находятся в RAM) с обработкой на какой нибудь из СУБД. Здесь одинаковых условий нельзя создать, чтоб сравнить. Ну я полагаю что хреновеньком железе (обычный пень) Delphi будет в лидерах (хотя x64 уже на анонсировали, возможно это изменит ситуац. и в др нише). Да и язык имеет больше возм. чем TSql, PSQL или PL-SQL. Ну и понятное дело там где для данные это не 3 плоских таблицы и нужен SQL то только СУБД.
Вот интересный пост в тему http://www.delphinotes.ru/2011/03/n-plsql.html . Что делает мужчина для переброса в RAM. Ну и там у него вполне кода может выйти больше чем для аналог. решения на выс.уров. языке (правда которое не справится с его объёмами данных).
>При чем здесь необходимость одновременно создавать и удалять миллионы объектов?
Задачи разные бывают. Если нужно отобразить 4 записи с БД в гриде, то повидимому это делать не нужно.
>Во-первых, этот тест как раз очень и очень показателен. Поскольку, он показывает, что качество конечного машинного кода, генерируемого .NET. очень высокое и сравнимо с найтивными компиляторами.
да только эти 8% на компиляцию, где-то могут и больше где-то и меньше. А если взять не 1 функцию а 1 форму с кучей компонентов VCL+Дев.Эксп.Гриды+Стили и WPF+Дев.Эксп.Гриды+Стили, как вы думайте какие там будут 8%?
>Во-вторых, я привожу реальные примеры с исходниками, а не голословные заявления, что какой-то там заказчик недоволен скоростью какой-то работы.
Я в отличии от Вас могу привести только голословные заявления, которые являются моим мнением и Вы можете с ним не соглашаться.
> Я под "круче" понимаю быстрее и мощнее, т.е за одно и тоже время обработает больше информации.
ОтветитьУдалить> Оракл + Не виндов.серв. + хорошее железо = решение которому сейчас врятле найдется конкурент.(Жалко что очень дорого)
Вы сами себе противоречите.
То вы говорите, что у вас нет возможности ставить крутые серверы типа Оракла у клиента и прикладывать к ним Админа для ваших небольших задач. То вдруг оказывается, что админ и сопровождение не причем, а только денег жалко. То у вас какие-то весьма специфические задачи, то вдруг они опять укладываются в схему клиент-сервер (был бы Оракл)...
> Об этом много интересных постов написано и во всех фигурирует одно название "Бесплатный сыр в мышеловке".
А вы сами из чисто альтруистических и научных целей программированием занимаетесь? ;)
Для малых и даже средних проектов зачастую вполне хватает и lite версий.
У меня, например, одна небольшая конторка уже пятый год на MSSQLExpress работают и ни одно из ограничений ( включая размер базы ) их пока не волнует.
А если контора разрастется, то не грех будет и заплатить за стартовую версию сервера.
> Тут не совсем-то о велосипеде речь идёт. Вот из всех СУБД...
Я, признаться, раза два прочел то, что вы написали, но так и не понял о чем вы..
Для того, чтобы оправдать то, что вы занимаетесь всей этой обработкой самостоятельно что ли?
> Задачи разные бывают. Если нужно отобразить 4 записи с БД в гриде, то повидимому это делать не нужно.
Одновременно создавать удалять и нова создавать миллионы "объектов" ( почеркиваю объектов ) в памяти для хранения однородных данных?
Это ИМХО бред, причем, безотносительно языка и среды.
По нормальному для этого просто выделяется участки/блоки/массивы памяти.
> да только эти 8% на компиляцию... А если взять не 1 функцию а 1 форму с кучей компонентов VCL+Дев.Эксп.Гриды+Стили и WPF+Дев.Эксп.Гриды+Стили, как вы думайте какие там будут 8%?
Погуглите про NGen ( стандартная утилита VS ). Даже никаких 8% ( хотя, по факту меньше ) на компиляцию тогда не будет.
> Я в отличии от Вас могу привести только голословные заявления...
Вот именно.
При этом, похоже, что вы не знаете .NET среду или имеете весьма поверхностное о ней представление ( это видно из ваших постов ).
Но тем не менее пытаетесь найти причину, почему она ( по вашему мнению, конечно же ) отстойнее Дельфей на основании чьих-то не очень вменяемых тестов ( про миллион объектов ).
Дело ваше, конечно. Только такие как вы рискуете скоро остаться в гордом одиночестве в качестве специалиста по дремучим системам.
ИМХО: Лучше все же не ограничивать себя рамками изучения одного языка.
>На нылых и плохо-оптимизирующих Паскалях, и в управляемых средах .Net/Java такие серьезные "CPU & Memory eating" приложения, как правило, не пишут.<
ОтветитьУдалитьНасчёт Memory eating... недавно сделал для себя открытие. Была необходимость реализации в DLL некоего алгоритма на С++ ранее написанного на делфях. Данный алгоритм подразумевал интенсивное выделение и освобождение кусков ОП различной длины. Цель перевода кода - устали ждать x64 копиляции в Delphi а памяти более 2-х гигов задействовать - очень заманчиво для нашего проекта (главное приложение уже переработали в среде MSVC++). Так вот, в ходе тестирования при средней нагрузке процесс не выдерживал длительного (не более часа) выполнения с новой DLL откомпилированной в среде MSVC++. При этом оперативной памяти задействовалось пару сотен МБ. В результате выяснилось, что приложение + ДЛЛ (напомню - реализованы в MSVC++) фрагментировали память в результате чего в определённый момент свободного куска нужного размера не находилось... Программируя больше на делфях я привык надеется что менеджер памяти за меня решает эту проблему... Чесно говоря, был очень удивлён, что в компании MS, зная что Windows сам эффективно не управляет распределением памяти, выпускает голый компилятр без средств управления её пользования. Данное заявление не голословно. Как раз пригодился недавно разработанный перехватчик API-вызовов. Через него проверил на вызов функции VirtualAlloc. На выполнение char* temp_buf = new char[8] приложение/длл попросит у системы 8 байт, что далеко не гуд. В модуле написанном на делфи память выделяеся кусками более 1МБ а затем она уде потом распределяется/собирается менеджером памяти.
После компильнул длл в Builder C++ - всё отлично заработало. Только вот более 2-гигов памяти мы так и неполучили по известным причинам. Писать свой менеджер памяти - дело трудозатратное.
Кстати, переработка менеджера памяти является ещё одним из тормозов перевода компилятора делфи на x64.
Почему об этом недостатке в хвалёном MSVC++ никто не упоминает?
ИМХО не думаю что в делфи он был реализован ради развлечения, попутно раскладывая пасьянс...Эффективное управление распределением ОП (оглядываясь назад) для многих моих приложений необходимо как воздух. Для тех приложений которые использует максимум несколько 10 Мб это значение может и не имеет.
И на последок - на паскале/делфи пишут очень серьёзное ПО, в т.ч. системное
>Вы сами себе противоречите.
ОтветитьУдалитьТо вы говорите, что у вас нет возможности ставить крутые серверы типа Оракла у клиента и прикладывать к ним Админа для ваших небольших задач. То вдруг оказывается, что админ и сопровождение не причем, а только денег жалко. То у вас какие-то весьма специфические задачи, то вдруг они опять укладываются в схему клиент-сервер (был бы Оракл)...
Ни где не противоречу.
Понимайте 2-звенка, и 3-х звенка, конечно можно к 1-му свести и говорить что это весьма специфическая задача. Но в 3-х зв. произв. увеличивается за счёт уменьшения конектов к БД и Буфферизации частых запросов. Поэтому можно поставить Оракл и сделать большую нагрузку, а можно всё это разнести и обойтись например бесплатным FB.
>Я, признаться, раза два прочел то, что вы написали, но так и не понял о чем вы..
Мои сожаления
>Одновременно создавать удалять и нова создавать миллионы "объектов" ( почеркиваю объектов ) в памяти для хранения однородных данных?
Можно 1-н объект создать, а внем милион записей. Думайте поможет?
>Вот именно.
При этом, похоже, что вы не знаете .NET среду или имеете весьма поверхностное о ней представление ( это видно из ваших постов ).
Но тем не менее пытаетесь найти причину, почему она ( по вашему мнению, конечно же ) отстойнее Дельфей на основании чьих-то не очень вменяемых тестов ( про миллион объектов ).
Я .NET постольку, поскольку. Пока для меня небыло нужды в этом. Пользуюсь плодами моих коллег.
Нормальный тест, проведите свой если он не нравится.
>Дело ваше, конечно. Только такие как вы рискуете скоро остаться в гордом одиночестве в качестве специалиста по дремучим системам.
О да.
>ИМХО: Лучше все же не ограничивать себя рамками изучения одного языка.
Согласен, пока только с изучением с использованием возникают проблемы...
> Почему об этом недостатке в хвалёном MSVC++ никто не упоминает?
ОтветитьУдалитьЭто не недостаток. Это просто более низкий уровень доступа к пямяти. Дельфина поверх этого использует еще и свой механизм оптимизирующий запросы к системе.
На VС++ для подобного используются похожие алгоритмы и механизмы. Существует куча решений. Погуглите сами.
Кроме того можно воспользоваться small-bloсk heap ( раборает быстрее )
Короче, у вас есть выбор, а на Дельфи просто готовое решение.
Зато, у этого готового решения есть серьезные проблемы с мультипоточностью прои работе внутри DLL ( нарывался на 7-ке еще ). Может пофиксили уже, не знаю.
Дельфи - это все же прикладной RAD уровень с более узкими рамками по сравнению с VC++.
Поэтому и сравнивать его лучше с C# и Java ( по области основного применения )
> Можно 1-н объект создать, а внем милион записей. Думайте поможет?
ОтветитьУдалитьНе думаю, а знаю. Есть существенная разница в том один раз память большим куском в куче запросить или миллион.
> Нормальный тест, проведите свой если он не нравится.
Сами авторы в конце намекают на нереальность этого теста. Я вам тоже не первый месяц уже долдоню про его абсурдность. Чего вам еще?
И тесты я уже приводил. Будет время, приведу еще.
>>Дело ваше, конечно. Только такие как вы рискуете скоро остаться в гордом одиночестве в качестве специалиста по дремучим системам.
>О да.
А-то нет?!
Дельфистов все меньше. Молодежь не ведется уже.
Даже спецов по экзотическому Objective-C куда больше стало ( хотя это в основном и для Apple ).
Ну что любитель С#, тесты какие нибудь появились?
ОтветитьУдалитьИли вы всё мерите быстродействие продуктов(качество) - количеством запросов(вакансий) на hh по языкам на которых они писались?
Будут тесты ознакомьте...
> Ну что любитель С#, тесты какие нибудь появились?
ОтветитьУдалитьМожно подумать, что мне больше делать нефиг, как только радовать вас очередными пруф-тестами :)
> Или вы всё мерите быстродействие продуктов(качество) - количеством запросов(вакансий)
> на hh по языкам на которых они писались?
Я уже ничего не меряю и самому себе ничего не доказываю.
Я уже пишу на C#, радуюсь продуманной удобности ( по сравнению с Дельфиной ) и сильно напрягаюсь, когда приходится поддерживать старые тексты на архаичной Дельфине.
>Можно подумать, что мне больше делать нефиг, как только радовать вас очередными пруф-тестами :)
ОтветитьУдалитьЯ пошутил, не обижайтесь.
Но тесты, а вернее их резул. действительно интересны..)
Как Вам новая XE2 ?
ну-ну.. продолжаете обкакивать другое и хвалить свое, которое, ура, освоили/пользуетесь..
ОтветитьУдалитьа знаете какой подтекст этих ваших убеждений пеной у рта ? А я умный, а я умный!
даже себе не признаетесь в том, для чего вы убеждаете остальных
тщеславие лезет из каждой строчки
неужели спокойно нельзя пользоваться тем, что вам подходит ?
басик - на здоровье!
дельфи или си - пожалуйста!
оракл - велкам!
аксесс билогейтовский - тоже пригодится
не устали ?)
до чего же скучно