Здравствуйте, Tihomir.I, Вы писали:
TI>Не улавливаю, что такое “лишние синтаксические сущности”. И про Delphi могу сказать, что сам язык(синтаксис) не является чем-то важным(т.е. обычный бытовой инструмент). А говоря про С++, гибкость языка часто упоминается, значит это важная составляющая?
Здравствуйте, Tihomir.I, Вы писали:
TI>Почему новые проекты предпочитают стартовать на других языках (Java, C#, С++)? TI>В чем существенные недостатки у Delphi, как у среды разработки?
Баги не фиксят. Нет фактической поддержки вышедшей среды.
Здравствуйте, Tihomir.I, Вы писали:
TI>Почему новые проекты предпочитают стартовать на других языках (Java, C#, С++)? TI>В чем существенные недостатки у Delphi, как у среды разработки?
Дело в том, что "по жизни" Delphi был продуктом с хреновым QA и очень "прогрессивным" маркетинговым отделом. В результате, в продукт на каждый релиз вваливались новые фичи, покупались целые компании для этого, но вскоре выяснялось, что фича недоделаная, продукт от сторонней компании тоже недоделаный, а ещё при интеграции с ними поломали кусок старого функционала — но это ж фигня, всё равно мало кто пользовался, так ведь? Главное пресс-релиз победный накатать. При этом реально необходимые для приведения своего продукта в современный вид фичи откладывались, снова откладывались, и снова...
— Юникодные контролы? Да кому это надо! Мы ж не китайцы.
— Компилер в 64 бита? Да пусть спасибо скажут, что не в Win3.1 пишут, хипстеры несчастные!
— Нормальная работа не из под админа? Да они там с жиру бесятся — настоящий программист всегда админ у себя!
— Безглючный дебагер? Да нормально всё, ну подвис пару раз — чё.
— Полноценная поддержка COM? Да кому эти прокси-стабы надо. И IDL у нас нормально генерится, почти 100% совместимо с Microsoft. Просто пользуйтесь нашим редактором для TLB, и ничем иным.
— VCL-компоненты? Инсталируйте в общую палитру IDE. Ну да, даже если этот компонент в одном проекте лишь надо. Ширины экрана хватит всем!
— Поддержка source control? Да, конечно, у нас есть плагины от партнёров. TFS — не, не слышал. Берите проверенное временем: SourceSafe, CVS, SVN...
— Бинарный DFM? У нас есть поддержка текстового DFM-формата, если файл не слишком большой. И незачем вам работать вдвоём над одним DataModule, всё равно там кроме хекс-дампов ничего нет! И это, какое Вы там слово сказали... Бранч? Что это? Зачем с ним мёржиться?
И вот этой фигни постоянно накапливающийся список, никто не решает "проблемы 20% пользователей". И об этом не задумываешься, пока сам не попадаешь в эти 20%. Но если попал — приходит понимание что "ты попал", а остальные 80% продолжают петь дифирамбы, пока.
Недавний финальный кумулятивный апофеоз всех этих проблем — Фреймворк FireMonkey, когда даже собственный Embarcadero-саппорт (за который тоже заплачено нефиговое бабло) днями и неделями изображает, что не может "воспроизвести проблему", несмотря на детальное пошаговое описание, и лишь по факту долгих боданий тебе сообщают "will be fixed in next major release" (читай — через полгода минимум). Приплыли.
P.S. Посмотрите на мой ник, если есть сомнения. Начинал с Delphi 1. Закончил в Delphi 2006. Безумно рад, что можно не пользоваться "этим" сейчас, но с удовольствием "тряхну стариной" если продукт приведут в production-ready состояние. Т.е. начнут решать проблемы 20% пользователей.
Здравствуйте, Klikujiskaaan, Вы писали:
K>Здравствуйте, velkin, Вы писали:
V>>А в Visual Studio как и в Windows хоть тресни, нет менеджеров пакетов. Максимум какие-нибудь массовые установщики софта, которые программисту не сдались. Майкрософт попросит за пользование всем этим десятки и сотни тысяч рублей и ладно бы. Но представьте, вам с одной стороны предлагают суперкар бесплатно, а с другой переломать ноги и выдать костыли за деньги.
K>Открой для себя nuget и chocolatey.
А в них нет пакетов которые мне нужны. Давайте возьмём самые популярные библиотеки.
---------
Самое мощное в мире открытое геометрическое ядро:
opencascade
Search for opencascade returned 0 packages
Search for "opencascade" returned 1 package FreeCAD 0.14.3700
А мне не нужен FreeCAD, мне нужна библиотека с примерами. Да, она работает и в линуксе и в винде, но в винде приходится всё скачивать и устанавливать вручную.
---------
На мой взгляд самый продвинуты открытый физический движок:
bullet physics
Search for bullet returned 26 packages
Search for "bullet" returned 2 packages
Но в этих пакетах его нет. Поиск по "bullet physics" тоже ничего не даёт.
---------
Да и ладно, может обойдёмся обычной 3d графикой:
openscenegraph
Search for openscenegraph returned 0 packages
Search for "openscenegraph" returned 0 packages
Может osg? Нет пакетов, ну и давай до свидание.
---------
Дальше продолжать? У меня внушительный список библиотек. Вот и выходит — "Какая гадость это ваша заливная рыба".
Думаете я не знал, что для винды пытались сделать менеджеры пакетов, которые по сей день ни на что не способны? Собственно говоря в 1998 году была такая IDE Visual Studio 6.0. Из неё пользовался Visual C++ 6.0. Потом перешёл в Visual Studio 2003 и увлёкся дотнетом. Но на Visual Studio 2005 моё терпение кончилось. В 2008 открыл для себя линукс, и кстати, в том году он был очень хорош, сейчас же это просто шедевр по сравнению с виндой. Хотя разные линуксы дают разные эффекты, к примеру, с пакетами deb очень надёжен Debian, а вот Ubuntu ненадёжен, зато обновляется чаще.
Так вот за все эти годы наблюдал одну и ту же картину, как майкрософт гасила конкурентов. Причём на мои потребности как программиста им было абсолютно наплевать.
1. Я не хочу полностью переучиваться каждые пару лет. Причём ладно бы мне давали новые возможности, так нет, всё тоже самое, только называется иначе и по другому сгруппировано. Зачем вы сделали тоже самое по новому? Ах да, вас же поджимали конкуренты, надо было выпустить очередной продукт, а старый бросить, оттянуть на себя программистов, взбаламутить рынок и заработать ещё несколько миллиардов долларов.
2. Мне нужны современные возможности, самые продвинутые библиотеки, бесплатные для коммерческого использования, открытые, чтобы я мог посмотреть код и лучше их понять, кроссплатформенные, если возможно они должны иметь ускорение за счёт видеокарты и прочие фичи. >>"Открой для себя nuget и chocolatey"
Но там же нет того, что мне нужно. >>"Открой для себя nuget и chocolatey"
Ну и что теперь опять вручную всё ставить, почему нельзя сразу начать использовать библиотеку. >>"Открой для себя nuget и chocolatey"
Я же говорю, нет там того, что мне нужно. >>"Открой для себя nuget и chocolatey" >>"Открой для себя nuget и chocolatey" >>"Открой для себя nuget и chocolatey"
Здравствуйте, Tihomir.I, Вы писали:
SNN>>Популярность дельфи была восновном на просторах бывшего ссср. С чем это связано, трудно сказать... Возможно с тем, что в то время дельфи и билдер были чуть ли не единственными RAD, и порог вхождения был ниже, чем в ту же Visual Studio с MFC
TI>Есть мнение, что RAD – это серьезная беда. Любой школьник может сесть и слепить программу на Delphi, но результат получается очень сомнительный. TI>На сколько помню, Builder вообще не был популярен среди С++ программистов.
Потому что добавлял ряд нестандартных элементов синтаксиса, которые другой компилер не понимал (и не мог понимать). Но именно UI многие из знакомых сишников рисовали на Билдере.
Здравствуйте, aloch, Вы писали:
A>И все равно остается ручное гроханье, а addref/release — это как я понимаю торчит из COM, там еще и рекурсивную ссылку словить можно.
там поддержка com встроена в язык и использование интерфейсов совершенно прозрачно. Рекурсивная ссылка — да, но ее и в плюсах не разрулить автоматически
A>И если мне не изменяет память я должен еще и конструктор и деструктор (Init()/Done()) сам руками вызывать. В общем все очень плохо.
Нет, зачем. Вызовятся сами при создании/удалении объекта
Здравствуйте, Tihomir.I, Вы писали:
TI>Почему новые проекты предпочитают стартовать на других языках (Java, C#, С++)?
Новые проекты стартуют с прицелом на кроссплатформенность, которого у Delphi фактически нет и видимо уже никогда не будет.
TI>В чем существенные недостатки у Delphi, как у среды разработки?
Ну во-первых — это убогость самого языка (к примеру нет аналога объектов на стеке, библиотеки типа STL разрабатываются кем попало и т.д.). Во-вторых — отсутствие кроссплатформенности (кодогенерация для макоси ужасна, про линух по-моему еще и бубуен не звенел).
Здравствуйте, Tihomir.I, Вы писали:
A>>Т.е. какие преимущества есть у Delphi по сравнению, например, с C#?
TI>Вы скажите. Я не знаю C#, поэтому трудно сравнивать. TI>Каждый язык программирования владеет какой-то своей нишей. Грубо: TI> Java — это кросcплатформенность TI> C++ — это гибкость синтаксиса, алгоритмичность языка TI> Delphi — это RAD, GUI
Нет, это не так. В самом Object Pascal или Delphi, если подразумевать язык, нет ни RAD, ни GUI. В C# тоже этого нет, как нет этого и в C++, и даже в Java. Возможности языка реализует компилятор.
Но помимо этого свиту короля играют IDE (среды разработки) и библиотеки. Ситуация сейчас такова, что C++ имеет библиотеки на все случаи жизни, чего нет ни в .NET C#, ни в Java, а хуже всего дела у Delphi.
Резонный вопрос, если C++ такое крутой, то почему он не победил ту же Java или даже C#. А дело в том, что программирование не вчера родилось, и 15 лет назад C++ не имел такого количества открытых и бесплатных для коммерческого использования библиотек. Даже Qt 4.8.x освободился от коммерческой лицензии, то есть стал LGPL не так давно.
Опять же в те времена (но не сейчас) вменяемой средой разработки была пожалуй лишь Visual Studio. В свою очередь со временем она стала сманивать программистов на .NET. В наше время самый мощный по возможностям язык(+библиотеки+IDE) это C++.
В свою очередь он вобрал в себя старые парадигмы — процедурную и функциональную. И ещё +ооп +обобщённое программирование. Одним словом С++, не просто Си.
От двух этих парадигм и отталкиваются программисты C++, причём они очень сильно различаются.
классика ооп: Qt 4.8.x
классика обобщённого: stl+boost
Хотя помимо этого есть огромное количество других библиотек. Важная особенность в совместимости между различными библиотеками, так как язык один, и единственное что нужно делать, это компилировать одним компилятором, или хотя бы совместимым.
1. С++ это кроссплатформенность
2. С++ (+библиотека и IDE) это RAD, GUI
3. С++ это огромное количество бесплатных и открытых библиотек для коммерческого использования
4. С++ это непревзойдённая скорость в стиле обобщённого программирования, и даже скорости в ООП проектах по сравнению с той же Java впечатляют
Java это 1 и 2.
C# это 2, Delphi тоже 2, только устаревшее, плюс они очень сильно завязаны на Windows.
Да и в конечном итоге всё сводится к C/С++. Сервера, которые запускают веб-языки тоже написаны на них. Или взять крупнейшие компании, может банк и может себе позволить Java, но почему-то с большими данными работают на C/С++. А драйвера на чём пишут.
Но вообще говоря вопрос, что лучше или хуже наивен. Мои задачи может решить только C++, ему просто нет аналогов. Но если человек написал сайтик на PHP, или выучил Python для связки с тем же C++, так и ладно. Если хватило кувалды чтобы забить сваю, то сваезабиватель не нужен.
Здравствуйте, Klikujiskaaan, Вы писали:
K>Здравствуйте, velkin, Вы писали:
K>У линукса действительно есть отличный момент, он оттягивает на себя подобных шериданов.
По опыту работы с линуксами могу сказать так:
2005 года выпуска:
Работают, но с windows xp им не тягаться. Менеджер пакетов, конечно, хорош, но дополнительное оборудование работает плохо. А это значит как десктоп плохо пригодны.
2010 года выпуска:
Оборудование стало работать гораздо лучше, но ещё не фонтан. Впрочем они уже не хуже windows, а новые её версии не радуют.
2015 год выпуска:
Удивительно, но теперь оборудование не работает в windows (XP, 7, 8.1) и прекрасно работает в linux. Причём даже то, которое раньше в linux не работало. Linux сразу ловит из коробки как то, что было выпущено 15 лет назад, так и то, что в выпущено в прошлом году.
И вот парадокс, теперь windows это удел гиков, которые любят эксперименты с оборудованием, а linux для домохозяек, которые не способны сделать больше пары кликов в гуишном меню.
Тоже самое касается программирования. Я могу из сорцов собрать библиотеки и программы со всеми зависимостями как в windows, так и в linux. Но в linux есть полный список и кнопка "установить", более того, после можно сразу использовать библиотеки в своих проектах вообще ничего не настраивая. Тоже самое касается и программ, и серверов и всего остального.
Вот и вопрос, кто после этого заумный гик, а кто домохозяйка. У меня параллельно так же установлен windows, если надо запускаю его через Grub, то есть просто выбрав в меню при включении компьютера. Но для программирования он плохо пригоден.
Более того, в Windows нет ничего игрового. Можно точно так же обсудить и эту тему заодно, DirectX vs OpenGL. Реальность же такова, что производители оборудования не дадут майкрософт взять себя за яйца, потому их реализация OpenGL работает нормально. А вообще вместо абстрактных рассуждений можно просто взять и запустить всё, что интересно.
Дни холиваров ушли в прошлое. На С++ потребуют знания или boost на одной работе, или Qt на другой. Если нужны деньги можно вучить Java, аутсорс на нём процветает. Delphi давно устарело, а С# это майкрософт. А майкрософт это война форматов, игра в несовместимость. Не верю, что такая корпорация умрёт как ей предсказывают, но те кто с ней связывался плохо кончили и это факт (программистам на заметку).
Здравствуйте, Tihomir.I, Вы писали:
TI>Почему новые проекты предпочитают стартовать на других языках (Java, C#, С++)? TI>В чем существенные недостатки у Delphi, как у среды разработки?
В своё время меня миновал ужас MFC, но писать под винду хотелось. Стал юзать Дельфи 2.0; Всё было хорошо, базы данных лепились играючи (да вообще любые приложения делались на ура!), да и в целом Дельфи на 146% оправдывал слово "визуальный" — большинство вещей делалось мышкой и продуктивность была на высоте. Но со временем целая куча факторов увела меня от Дельфи, о чём я сейчас ничуть не жалею:
Из версии в версию не наблюдал никакого прогресса с существующими контролами — как была кнопка, так она, убогая, и кочует. Как было "никакое" поле ввода — так оно и приплыло аж в дельфу-7. Эта стагнация наводит уныние, ведь у контролов был целый ворох вещей, которые можно и нужно было улучшать! Но почему-то "шахматистам" из Борланда допиливание фич не казалось таким нужным/интересным. За что и поплатились.
Синтаксис. Увы, мне эти begin-end до кишок достали!! У меня и так в программе сотни функций и переменных, зачем мне ещё читать "мусор", обозначающий тривиальные вещи?? and, or, begin, end, for-to-do... мне не нужно читать листинги вслух, мне нужно краткое выражение алгоритма! А объявление всех переменных вначале? Нафик мне это нужно?? Это комп должен работать и собирать переменные, а я — ДУМАТЬ! Поэтому с первым же "си-подобным" C# вопрос "на чём писать" решился сиюсекундно.
Как уже отметили, Борланд покупал "овно" и совал в IDE, хотя это были очевидно сырые (но, видимо, дешёвые?) продукты. Почему-то никто не купил DevExpress'овский грид — король всех гридов! А помоечные Indy компоненты — пжалуйста, деньги про*рали. Никто даже не упомянул хотя бы переговоры купить TAdvStringGrid, зато QuickReport уверенно кочевал, хотя FastReport был круче его на голову. В общем, Буглэнд-маркетоиды, очевидно даже не спрашивая программистов, напокупали всякого фуфла и этим поставили крест на себе.
С появлением ДотНЕТа ещё никто не знал, во что он выльется, но зато было очевидно, что Дельфи там — "чужой". И надо было опять какому-то *удаку вылезти с идеей "а давайте дружно прыгнем на .NET!" — ЗАЧЕМ?? VCL и так был прекрасен, именно на платформе Win32! Продолжи буглэнд допиливать свою среду, они ДАЖЕ СЕЙЧАС ничего не проиграли бы — всё так же люди пользуют XP/7/Win32/64 и хрен клали на мелкомягкие затеи! Это судьбоносное решение принял полный кретин, вбив очередной гвоздь в будущее Дельфы — все прекрасно понимали, что имея компоненты дотнета, VCL (в котором они стали профи) стал нафик не нужен (тем более портированный). Так нафик вообще нужен Дельфи, если не за его библиотеку??
VisualStudio. Мы все помним тот кусог овна, который она представляла в версии "6". Но извините, уже сидя в студии 2005 я понял, что микрософт ОПЕРЕДИЛА годами писанную Дельфу! Код писался буквально вылетая из-под пальцев, всякие интеллисенсы реально экономили время, ну и C# тоже начинал вставлять — простота и лаконичность языка сыграла катализатором. Библиотек тоже было навалом даже "искаропки", чего не скажешь о многострадальной Дельфе, которую без доп.компонент юзать невозможно.
Ну и чисто личный момент: чувствуя потенциал C# и дотнета, стал серьёзно изучать тему. Всё ещё работая дельфизоидом. Ну а как попалась компания, нанимающая шарповодов, вопрос о Дельфи вообще отпал — нет смысла возиться в стагнирующем болоте, да ещё руководимом какими-то лунатиками.
Понятно, что постфактум мы все умные, но решение об уходе с Дельфы я принял вовремя и объективно — все аргументы выше. Дельфи БЫЛА хорошей средой, но тупорылый маркетинг её убил.
Сейчас все проекты пишу на C#, даже "однострочники" и "однодневки". Ну и на Немерлю поглядываю
Здравствуйте, btn1, Вы писали:
B>Здравствуйте, Tihomir.I, Вы писали: B>... B>Сейчас все проекты пишу на C#, даже "однострочники" и "однодневки". Ну и на Немерлю поглядываю
Вполне объективно. Но к сожалению C# идёт на платформе .NET. А это значит:
1. Нет кроссплатформенности. Обсуждать тот же Mono и работу под Wine на мой взгляд несерьёзно.
2. Код в принципе (без обфускаторов) открыт с помощью декомпиляции, хотя и не бесплатно (ну это ж майкрософт).
.NET Reflector — платная утилита для Microsoft .NET, комбинирующая браузер классов, статический анализатор и декомпилятор, изначально написанная Lutz Roeder.
3. Майкрософт постоянно выпускает новые верссии .NET. Почему бы не прокачать одну? Но нет, так было бы слишком просто для программистов. А пользователи теперь пусть устанавливают пакеты со всеми версиями.
4. Отсутствие библиотек, которым нет аналога. Так уж получилось, что даже не столь экзотические библиотеки будут портом библиотек С/C++.
5. Qt 4.8.x ничуть не хуже .NET любой версии. Есть, и другие проекты, на вроде GTK+, WxWidgets и прочие, но это дело десятое. Важно, что Qt 4.8.x полностью убирает потребность в такой мощном фреймворке как .NET. Но при этом Qt кроссплатформенный и его легко использовать с другими библиотеками C++.
Самое печальное во всём этом, что если отследить на чём выехали крупнейшие софтовые корпорации, то окажется это C/C++. Хотя если ваши проекты в будущем не претендуют на мировое господство, то можно и плюшками (си шарпом) баловаться.
Здравствуйте, Tihomir.I, Вы писали:
TI>Про войну библиотек не уловил. В чем преимущество?
Не надо изобретать велосипед для вещей,
— ставших стандартами де-факто: JSON, ZIP, сетевые протоколы
— набирающих популярность (всякие твиттеры-социалочки, хипстерские Фреймворки, облачные сервисы-гит и т.п.)
Т.е. либо пилишь руками порт из чего-то опенсорсного, либо пытаешься синтегрироваться с готовыми бинарями. Но на всё это надо время, что не приближает к успешному релизу.
V>.NET Reflector — платная утилита для Microsoft .NET, комбинирующая браузер классов, статический анализатор и декомпилятор, изначально написанная Lutz Roeder.
Или бесплатный ILSpy (сделанный как раз по поводу перехода Reflector на коммерческие рельсы)
V>3. Майкрософт постоянно выпускает новые верссии .NET. Почему бы не прокачать одну? Но нет, так было бы слишком просто для программистов. А пользователи теперь пусть устанавливают пакеты со всеми версиями.
Здравствуйте, aloch, Вы писали:
V>>3. Майкрософт постоянно выпускает новые верссии .NET. Почему бы не прокачать одну? Но нет, так было бы слишком просто для программистов. А пользователи теперь пусть устанавливают пакеты со всеми версиями.
A>А для Qt все по другому?
В настоящее время Qt стабилизировался на версии 4.8.6. Для примера OpenCASCADE без проблем интегрируется в Qt, внутри есть готовые примеры, сразу можно увидеть как загружаются и отображаются различные форматы (STEP, IGES). Если взять OpenSceneGraph, то так же присутствует поддержка Qt, более того, виджеты из Qt могут отображаться внутри 3D видов OpenSceneGraph. Ещё для примера OpenSceneGraph совместим с BulletPhysics, тоже через плагин, и всё это можно отображать посредством Qt.
И подобных примеров масса, совмещаются все парадигмы, процедурная, функциональная, объектно-ориентированная, обобщённая. К примеру, Qt легко подключить к OpenCV, причём обе системы так спроектированы, что не обязательно копировать между QImage и cv::Mat, можно просто ссылаться на данные другого класса.
Можно, конечно, сказать, что есть Qt 5.x. Но вот в чём вопрос, что это такое, для кого сделано, и самое главное кем. Это как если бы одну версию .NET делал майкрософт, вторую гугл, а третью эпл. Считаю, что главный урок, который даёт Raspberry Pi в том, что на нём работает всё тоже самое, что и в линукс (тот же Debian), а значит и в Windows, BSD, MacOSX и других.
В свою очередь возникает вопрос, почему этого не могут планшеты и телефоны, ведь у них такая же начинка. А ответ в том, что они могут, если поставить на них тот же линукс. И как думаете, что творится у корпораций в "голове", а именно Гугла, Эпла и Майкрософта. Всё банально, заработать деньжат. Невыгодно делать совместимые решения, даже если всё "кричит" об этом.
Обычный же программист попадает в мясорубку конкурентной борьбы гигантов. А многие из программистов и жизни то хорошей не знали. Так и кодят на дельфях, да на дотнете. А им ещё сверху теперь ...ут на мозги, что дескать у нас теперь везде мобильное программирование, новое уникальное знание — кастрированный линукс.
И вот как и в стародавние времена рвут программистов на части. Но со временем даже нынешняя молодёжь осознает, что нет у них смартфона или планшета, в их руках обычный компьютер. Думаю в будущем распространятся компьютеры флешки, в том числе и нано формата, компьютеры часы, компьютеры очки. Всё это уже есть, и это обычные компьютеры.
То что сейчас делают программисты не используя кроссплатформенные системы отправится в унитаз. Кроссплатформенное будет просто перекомпилировано. Здесь мы подходим к философской проблеме: — "Зачем работать в унитаз?".
Вот смотрите, что сделал майкрософт, дал возможность писать программы для .NET. Но если он не захочет, программист не вскочет. Иными словами, если ему будет не выгодно, чтобы ваши программы работали на линуксе, макосе, или на новых версиях винды, то они и не будут работать. Достаточно просто не выпустить платформу для этих версий и вуаля.
Предположим у вас солидная фирма, создаёт программные продукты. Но нет батюшка, тушите свет, отправляйтесь на помойку истории, потому что великий и ужасный майкрософт опять с кем-то поцапался и решил всё запретить. Причём не забываем, что майкрософт стоит денег и ваш бизнес никогда не будет масштабируемым.
А противостоят ему железные гиганты, сиречь производители оборудования. Их вовсе не устраивает тявкать вокруг какого-то софтовика. Себя они видят волкодавами. Кроссплатформа это не просто блажь или битва за клиентов, кроссплатформа это борьба за независимость.
Независимость от производителей операционной системы, независимость от производителей железа. Аутсайдер, тот кто всегда в конце списка, это и есть лицо современного программиста. И зарплата здесь не играет никакой роли.
Настанет день и майкрософт аннигилирует дотнет, и будет всем очень смешно. А если не верите, почитайте его историю, или вспомните что он вытворял на протяжении последних десятилетий.
Что касается Delphi, то он уже аннигилировался. С чего бы его выбирать, если хотя бы вот, архитектуры поддерживающиеся дебианом, а значит C++ и всеми кроссплатформенными библиотеками.
i386 — архитектура x86, разработана для Intel-совместимых 32-битных процессоров
amd64 — архитектура x86-64 разработана для Intel/AMD 64-битных процессоров
sparc — архитектура Sun SPARC для систем Sun4m, Sun4u и Sun4v
armel — архитектура ARM для Risc PC и различных встраиваемых систем
powerpc — архитектура PowerPC
ia64 — архитектура Intel Itanium (IA-64)
mips, mipsel — архитектура MIPS (big-endian и little-endian)
s390 — архитектура IBM ESA/390
The operating system, must be one of: (Q_OS_x)
DARWIN — Darwin OS (synonym for Q_OS_MAC)
SYMBIAN — Symbian
MSDOS — MS-DOS and Windows
OS2 — OS/2
OS2EMX — XFree86 on OS/2 (not PM)
WIN32 — Win32 (Windows 2000/XP/Vista/7 and Windows Server 2003/2008)
WINCE — WinCE (Windows CE 5.0)
CYGWIN — Cygwin
SOLARIS — Sun Solaris
HPUX — HP-UX
ULTRIX — DEC Ultrix
LINUX — Linux
FREEBSD — FreeBSD
NETBSD — NetBSD
OPENBSD — OpenBSD
BSDI — BSD/OS
IRIX — SGI Irix
OSF — HP Tru64 UNIX
SCO — SCO OpenServer 5
UNIXWARE — UnixWare 7, Open UNIX 8
AIX — AIX
HURD — GNU Hurd
DGUX — DG/UX
RELIANT — Reliant UNIX
DYNIX — DYNIX/ptx
QNX — QNX
LYNX — LynxOS
BSD4 — Any BSD 4.4 system
UNIX — Any UNIX BSD/SYSV system
The compiler, must be one of: (Q_CC_x)
SYM — Digital Mars C/C++ (used to be Symantec C++)
MWERKS — Metrowerks CodeWarrior
MSVC — Microsoft Visual C/C++, Intel C++ for Windows
BOR — Borland/Turbo C++
WAT — Watcom C++
GNU — GNU C++
COMEAU — Comeau C++
EDG — Edison Design Group C++
OC — CenterLine C++
SUN — Forte Developer, or Sun Studio C++
MIPS — MIPSpro C++
DEC — DEC C++
HPACC — HP aC++
USLC — SCO OUDK and UDK
CDS — Reliant C++
KAI — KAI C++
INTEL — Intel C++ for Linux, Intel C++ for Windows
HIGHC — MetaWare High C/C++
PGI — Portland Group C++
GHS — Green Hills Optimizing C++ Compilers
GCCE — GCCE (Symbian GCCE builds)
RVCT — ARM Realview Compiler Suite
NOKIAX86 — Nokia x86 (Symbian WINSCW builds)
CLANG — C++ front-end for the LLVM compiler
The window system, must be one of: (Q_WS_x)
MACX — Mac OS X
MAC9 — Mac OS 9
QWS — Qt for Embedded Linux
WIN32 — Windows
X11 — X Window System
S60 — Symbian S60
PM — unsupported
WIN16 — unsupported
Java тоже, сколько смотрю, отличные функциональные приложения, но скорость исполнения просто жесть. Тормозит, тормозит, тормозит. На что они рассчитывали, что я введу сто узлов, а я ввёл несколько тысяч, и что, теперь будем тормозить? На C++ почему-то такого не происходит, он и лимон переварит без проблем. Красивые конструкции, никакой оптимизации. И так из приложения в приложение.
Но вернёмся с дотнету. Основная проблема как уже было сказано — аннигиляция продуктов во славу майкрософта. Какое может быть будущее, если не знаешь чего ждать. Ещё раз напомню, те кто используют дотнет целиком и полностью от него зависимы. Это не есть хорошо, даже если забыть о небольших возможностях и неспособности увеличить (масштабировать) бизнес не отбашляв майкрософту за каждый компонент.
Выводы:
Ну и что, что Java тормоз, вы же не поисковик гугла пишите, и не антивирусник, и не CAD/CAE/CAM систему, не управление роботами, и не новейшую игру ААА класса. Если какой-нибудь банк хочет нанять вас программистом Java или аутсорсер не прочь нагреть на вас руки, и вас не обидеть, то почему бы и нет.
На дворе 2015 год, а вы не слышали о других операционных системах кроме винды и даже не подозреваете, что многие виндовые приложения просто портируют в винду за счёт кроссплатформенности, а на самом деле пишут в других осях. Пишите на дотнете, всё равно ваши скрипты мало кому нужны. Ну или если майкрософт заморочил "голову" очередному богатому дурачку и он теперь нанимает дотнетчиков, то почему бы и нет.
Мы говорим о Delphi? И это "в то время, когда наши космические корабли бороздят просторы Вселенной". В общем если платят, пишите хоть в TurboPascal, а если нет или всё равно, для себя выбирайте лучшее.
Здравствуйте, Tihomir.I, Вы писали:
TI>Почему новые проекты предпочитают стартовать на других языках (Java, C#, С++)? TI>В чем существенные недостатки у Delphi, как у среды разработки?
В целом все верно, но вот тут ты не прав:
V>Java тоже, сколько смотрю, отличные функциональные приложения, но скорость исполнения просто жесть. Тормозит, тормозит, тормозит. На что они рассчитывали, что я введу сто узлов, а я ввёл несколько тысяч, и что, теперь будем тормозить? На C++ почему-то такого не происходит, он и лимон переварит без проблем. Красивые конструкции, никакой оптимизации. И так из приложения в приложение.
Java, сама по себе, не тормозит. Но, приложения написанные на Java очень часто тормозят. Возникает вопрос почему и утверждения что язык тормозной. На практике же, это побочный эффект широко распространного в Java подхода "сделать как можно больше абстракций и фабрик". Если же писать на Java в C++ стиле (видя такое богохульство, большинство истинных Java разработчиков начинают тонны кирпичей откладывать и талмуды по паттернам доставатьь), то проиводительность получается очень даже приличная, максимум на 20-30% хуже, чем если бы ты писал на C++. Вобщем, проблема медленной Java — она в головах.
Здравствуйте, kaa.python, Вы писали:
KP>Java, сама по себе, не тормозит. Но, приложения написанные на Java очень часто тормозят. Возникает вопрос почему и утверждения что язык тормозной. На практике же, это побочный эффект широко распространного в Java подхода "сделать как можно больше абстракций и фабрик". Если же писать на Java в C++ стиле (видя такое богохульство, большинство истинных Java разработчиков начинают тонны кирпичей откладывать и талмуды по паттернам доставатьь), то проиводительность получается очень даже приличная, максимум на 20-30% хуже, чем если бы ты писал на C++. Вобщем, проблема медленной Java — она в головах.
Действительно, на Java можно создавать быстрый код, но только это будет код не в C++ стиле. И даже стилем C это можно назвать только с натяжкой — в Java нет даже структур, и при создании быстрого кода их приходится эмулировать.
В C++ есть дешёвые и даже зачастую бесплатные механизмы абстракции, в Java их нет — и соответственно быстрый код на Java по размеру будет намного больше чем аналог по скорости на C++.
То есть даже если отбросить подход "сделать как можно больше абстракций и фабрик", то всё равно будет тормозить. Быстрый код получается посредством отказа от полиморфизма, отказа от GC и эмуляцией структур — в результате остаётся крайне ограниченное и неудобное подмножество языка (на котором писать в "C++ стиле" уж точно никак не получится).
.jpg)
