Тут есть ряд аспектов, технологических, исторических, политических, экономических, (о-боже!) маркетинговых :)
В до-FireMonkey-овский период были стремления Embarcadero сделать библиотеку визуальных компонентов, выходящую за рамки Windows. Совсем углубляться в историю с CLX сейчас смысла большого нет. Тогда тоже были «кроссплатформенные» инициативы, вызванные рыночной ситуацией (Linux в предустанове шёл практически на каждом втором ноутбуке — ну или по крайней мере был заметен в качестве бизнес-настольной ОС — не путать с «вашей» домашней настольной ОС — разные вещи). Почему Linux не стал «альтернативой» — вопрос очень интересный. Факт более высокой стоимости владения? Маркетинговый разгром? Предчувствие облаков и снижение интереса к настольным баталиям? Стоимость Windows-компетенции сисадмина vs «Линуксоида»? Протекционизм? Возьмём узкий сегмент — школы. Деньги экономит школа/гос-во, а напрягаюсь я (учитель). Хотя есть и специалисты с опытом (не) успешного распространения Linux, которые, возможно, захотят пролить бОльший свет, хотя общая тема здесь другая.
Закончу лишь тем, что Kylix до сих пор продаётся/используется.
К релизу Delphi XE назрела необходимость сделать что-то новое. Если компания (от поставщика йогуртов до автопрома) не выдаёт ежегодно что-то новое (желательно революционное), то начинаются здоровые сомнения в её (блин) креативных возможностях. А имиджевая составляющая в IT (какими бы функциональными прагматиками мы, разработчики/пользователи, себя бы не считали) очень высока. Можно сказать, выше не бывает, т.к. мне продают функционал, полезность которого я могу оценить только в перспективе, а чем выше уровень технического совершенства, тем дальше эта перспектива. А тут нам (Embarcadero) хорошо поддал рынок с 16% доли Mac-ов в корпорациях США и хорошим ростом на фоне стагнации десктопных Windows-машин. Было принято решение сделать VCL+ и ей-же войти в новый сегмент средств разработки под Mac OS.
VCL+ была хорошей идеей, Mac OS с хорошей имиджевой составляющей особенно в контексте ЛПР в нашем случае «двигал» средства разработки за собой (хотя, в большинстве случаев, бывает и наоборот). Перед инженерами Embarcadero встала задача разделения VCL на функционально-поведенческий и визуализационный уровень. Пилёжка VCL оказалась чуть сложнее, чем распиливание барышень в ящике, WinAPI слишком жёстко был прописан в генах этой библиотеки (что ранее как раз и было громадным её преимуществам, качество визуальных приложений на её основе не уступало «нативным» тулзам). Создавать «Delphi for MacOS» с полностью различными исходниками относительно классических «Delphi for Windows» было плохой идеей – биться сразу на двух фронтах (с Visual Studio и с Xcode) Embarcadero явно не улыбалось.
Выло выбрано следующее стратегическое решение. Слово «стратегический» здесь нужно воспринимать неэмоционально. Просто «стратегия» означает – линия поведения в ситуации неопределенности – такова стратегия IT-рынка средств разработки. Вместо деления VCL с весьма сомнительными перспективами в плане совместимости со «старыми» VCL-неразделёнными кодами, компания Embarcadero решила взять новую библиотеку. Да, она в прототипе основывалась на KSDev с последующим развитием и ре-брендингом в FireMonkey (сейчас «платформа FM»).
FireMonkey изначально основывалась на единстве функционального поведения (кнопка нажимается, «поле ввода» получает символы, чекбокс – чекится), при вариациях механизмов отображения – Quartz для Mac OS и DirectX (и GDI+) для Windows. Тут и проявлен «исторический» аспект «не-нативности» контролов FireMonkey. Уже были известны библиотеки, «рендерящие» в GPU-based режиме. Для Mac OS это вообще не было проблемой, а хилые Windows-машины оставались на откуп общей генеральной линии развития аппаратного обеспечения компаний (GDI+ был оставлен именно по этой причине). Вышла Delphi XE2, которая включала не только VCL практически без изменений, но и новую библиотеку кроссплатформенной разработки на основе единого кода FireMonkey.
Технология дала основу для достаточно вменяемого и, как оказалось, эффективного маркетинга.
— VCL forever – весь legacy-код будет эффективен и работоспособен;
— Delphi готова к освоению новых платформ.
В довесок Embarcadero усилила инструмент 64-битным компилятором и занесла ногу на поле iOS. В релизе XE2 можно было создавать «нативные» приложения для iOS с использованием той же самой FireMonkey. Object Pascal – он и в Африке такой (в буквальном смысле этого слова, в ЮАР принята гос-программа обучения на Delphi), а рендеринг/отображение компонентов сводится к элементарным операциям отрисовки графических примитивов.
Технологически – функциональность визуальных компонентов неизменна, под конкретную платформу на уровне сервисов подключается «аппарат рисования». Конечно, это – не «нативные» конторы. Зато интерфейс был 100% единый кроссплатформенный на уровне дизайнера Delphi.
Рынок отреагировал на это ростом более 50% продаж средств разработки Embarcadero поколения XE2. Разработчикам – пользователям Delphi – очень понравилась идея сохранения компетенции в современных динамически изменяющихся условиях в сфере платформ. Маркетингово это звучит как one «codebase – one team – one project schedule». Проблема «нативности» контролов никого не парила – поверьте, большинству разработчиков важны интегральные качества инструмента разработки, а не мифическая близость к платформе. В целом, идея хорошо проинвестированной технологии быстро вылилась в растущий имидж Delphi, сказалась на росте и послужила основой дальнейшего развития.
Если в области Windows-desktop-client-server-rich-GUI-разработки Delphi начинала с тотальной монополизации, то вход в рынок средств мобильной разработки требовал сверхусилий. VCL оставлена была «как есть» из-за невозможности четкого выделения границ функциональности/отображения. А без этого всё-равно получалась не «новая VCL с нативным отображение», а «ещё одна VCL для Mac OS» или iOS или Android и т.д. Достаточно дерзкая попытка взять iOS из Delphi XE2 при помощи конвертации проекта в Xcode и до-компилирования Free Pascal Compiler для ARM удалась. Но полноценное решение появилось в Delphi XE4 на основе своего компилятора и полного отказа от Xcode.
Возвращаясь к теме дискуссии – «нужны ли нам нативные контролы в противовес рисованными руками»? Ещё раз хочется подчеркнуть, что тема – не чисто технологическая. Любое инженерное решение должно основываться на комплексе показателей. Но есть же средства мульти-платформенной разработки, которые используют нативные конторлы? Да, есть, но они не идеальны. Сохранение единства кода и дизайна интерфейса сильно под вопросом. В смысле, что вопроса то и нет, т.к. нет единства. Есть «скриптовики» и «гибридные» средства. Но нативный исполняемый код и нативный интерфейс при 100% едином исходном коде – это проблема, которая должна быть решена. Подход Embarcadero в том, чтобы (возможно) придти к «нативному» решению от «рисованного», тогда как можно было тормознуть релизы (XE4 – iOS и XE5 – Android), чтобы «впилить лобзиком» нативные контролы в FireMonkey.
Чуть коснёмся проблематики FM vs VCL (и далее “VCL.mobile” – мне вполне нравится это название). Когда вводили новую библиотеку FireMonkey, конечно, был вопрос. Сделать их максимально близкими для облегчения миграции (хотя бы на уровне свойств-событий) или сбросить оковы «совместимости». Пошли вторым путём, FM сильно отличается от VCL. Победителей не судят, а мессидж «FireMonkey – не VCL» был воспринят спокойно. Все-таки кроссплатформенный (и далее мобильный) проект обычно новый и мало тащит за собой коды прошлых desktop-проектов.
Нативизация – проблемы и задачи.
Не-нативность (рисованность) контролов FM дала гигантское ускорение. Для покрытия новой платформы потребовалось лишь создать новый платформенный стиль (чуть больше, чем просто «шкурка» или «скин»). Это дало возможность в 2013 году обеспечить поддержку и iOS, и Android. Некоторые «особо злые в плане само-рисования» контролы уже нативные («календарчик», к примеру).
Нужна ли FM истинная нативность? Вопрос реакции пользователей (разработчиков мобильных приложений). Пока наблюдается достаточно ярко выраженная реакция что: «наконец-то Delphi делает под Android/iOS» с весьма весомым притоком пользователей Visual Studio и Xcode в ряды «дельфистов». Скорее всего, задачей будет в первую очередь дальшейшая стабилизация как платформы FM, так и IDE в целом, а нативизация будет там, где она критична. По крайней мере на ближайшую перспективу, о чём было сказано при обсуждении roadmap выше.
>>FireMonkey делается в России нашими разработчиками, может будет проще напрямую, или с вашей помощью отписаться о багах?
Да, платформа FM делается российскими разработчиками, но не только ими. Вообще, сложно разделить производственные подразделения компании на «Россию» и «не-Россию».
Самое эффективное — описывать баги на qc.embarcadero.com, т.к. это есть прямой путь. Есть хорошие новости — в ближайшем roadmap обозначены явные намерения сделать технологию более стабильной (ссылка не вставляется, но edn.embarcadero.com/article/43677).
>>Я тоже писал приложение на конкурс, калькулятор с возможностью строить графики.
Компонент TChart вполне применим, на Nexux 7 мне удавалось воспроизвести достаточно насыщенные построения графиков.
>>но на телефоне получил ужасные тормоза в функции
Печально читать, но в ближайшее время мы озабочены проблемами стабильности и быстродействия (см. roadmap). Надеемся, что в ближайшее время большинство проблем будут устранены.
Спасибо за проведённые исследования. Если Вам удалось наловить ошибок, пожалуйста, создайте на них отчёт в qc.embarcadero.com, так они гораздо быстрее будут рассмотрены инженерами по качеству.
Что касается AppMethod — да, это «подвид» Delphi для новых не-дельфи-пользователей.
Язык теперь называется Object Pascal.
Сама IDE претерпела некоторые изменения косметического характера, т.к. базовый функционал IDE не требовал каких-то особых доработок при переходе от «настольной» к «мобильной» разработке.
Проведенный конкурс www.delphimobile.ru/ показал, что в широком диапазоне приложений (19 поданных проектов) Delphi for Android вполне работоспособна как инструмент создания приложений.
Процесс фиксации багов — нужно понимать — требует времени и помощи со стороны пользователей. Т.е. запощивания ошибок на qc.embarcadero.com, который — поверьте — очень внимательно прорабатывается.
Скажу так — по результатам неформального общения с участниками конкурса я также сформировал кумулятивный wish-list, который передал инженерам и который будет «исполнет» в ближайшее время.
Что же до AppMethod — да, это Delphi минус VCL.
Для корпоративных разработчиков останется «старая-добрая Дельфи» со всеми-всеми возможностями (настольная + мобильная разработка).
Для «индивидуальных» разработчиков будет реализовываться «новый-злой Аппметод» с удобными и доступными вариантами приобретения, ориентированными на быструю окупаемость лицензии за счёт продаж продукта через магазины приложений.
Да, Вы — абсолютно правы, есть досадные ошибки, но в целом технологическое ядро (для Delphi и AppMethod) в контексте мобильной разработки вполне эффективно. Остальное — дело эволюции и стабилизации продуктов, чем усиленно занимается Embarcadero в последнее время!
С уважением,
Всеволод Леонов
Developer Evangelist
Embarcadero Technologies,
Russia and CIS
Спасибо за Ваши тезисы, открытая полемика никогда не вредила отдельно взятому подходу, если приверженцы не пытаются обосновывать свои позиции «вопросами веры».
Если в противопоставлении схемы обучения
Delphi — C++
нам предъявляется
VB.NET — C#
то появляется возможность перевести дискуссию в более-менее осмысленное русло, что позволяет говорить предметно.
VB.NET при достаточно спорном заявлении о «большей доступности, нежели Delphi/Pascal» в силу исторических обоснований самого факта своего появления не является языком профессиональной разработки. С одной стороны, можно достаточно уверенно поставить знак равенства между C# и VB.NET. С другой — в эпоху массового перехода на платформу .NET я не могу привести примеров, когда программисты выбирали VB.NET, а не C#. В России мне такие примеры неизвестны, хотя, в частности, в США еще в до-дотнетовскую эпоху VB считался вполне приемлемой компетенцией в плане зарабатывания денег. Хотя и здесь можно говорить о «попсовости» C#/.NET, т.к. сама корпорация Microsoft при разработкt программного обеспечения «на продажу» использовала и использует другие технологии разработки. В России в профессиональной среде VB.NET вызывал недоумение, а любой «изолированно-само-обучившийся» VB.NET-у специалист при первом же трудоустройстве пересаживался на C#.
Это подтверждает тезис, что языковая группа Visual Basic всегда была менее профессионально-пригодной, чем Delphi/Pascal.
Двинемся дальше в сторону обоснования миграции с VB.NET на C#. VB.NET настолько «подобен» C# (см. п. 2 выше), что качественного роста и расширения сферы познаний в области языковых средств для разработки ПО такой переход не даст. Приведу аналогию:
изучение VB.NET и переход на C# с точки зрения лингвистики весьма близко иллюстрируется началом изучения первого иностранного языка — испанского, а затем переход на португальский. Или из русского в украинский. Слишком близка грамматика и слишком родственны корни в силу технологического базиса (.NET).
Но является ли C# сам по себе универсальным? Давайте посмотрим на программу прошедшей конференции Microsoft www.msdevcon.ru/2013/schedule доклад F01. Там была попытка «увести» разработчиков от C# в мир С++, что не является безболезненным. Можно ли доверять C#, если сама Microsoft в общении с разработчиками как минимум не демонстрирует уверенности. Еще раз хочу напомнить конференцию Microsoft DevCon 2011, где явственно присутствовал C++ в качестве рекомендованных языковых средств.
На выходе мы имеем:
— VB(.NET) менее «профессионален», чем Delphi/Pascal при соизмеримой простоте в плане освоения;
— C#(.NET) менее востребован, чем C++ в плане широты охвата платформ, включая же платформы Microsoft.
Поясню диаграммой:
Работа по первой схеме учащиеся получать меньше, чем по второй.
В завершении немного о «кроссплатформенности» C#. Да, Xamarin даёт возможность использовать C# для программирования под iOS и Android. Но во-первых, единство исходного кода всего проекта для одновременной поддержки нескольких платформ требует работы, работы и еще раз работы. Во-вторых, инструмент Xamarin пока решает достаточно понятные прагматичные задачи, а их «ценник» выглядит более, чем впечатляющим. Здесь ценовая политика никак не коррелирует с «материнской средой» Visual Studio по очень понятным соображениям.
Разработка под Windows Phone в плоскости бесплатного использования Visual Studio, конечно, важна, но не на столько, чтобы говорить серьёзно с учётом распространенности этой платформы, включая учащихся и преподавателей. Опять же — учитывая имидж Windows Phone в молодёжной среде.
По части наличия других сред и реализаций языков — тут нужно учитывать специфику образовательного сегмента. Это и учебно-методические материалы, унификация которых в масштабах страны есть задача приоритетная. Это и сами затраты (как в денежном выражении, так и в виде человеко-часов), которые преподаватели Delphi/Pascal должны потратить на переход на другой язык по абсолютно непонятным причинам). В качестве примера могу дать следующее. В некоторых государствах в силу исторических причин обучение определенным предметам в школах/среднеспециальных/высших учебных заведениях велось на русском языке. Смена русского языка на другой, пусть даже и национальный, ведет за собой необходимость переписать и переиздать все учебники. Даже ярые противники русского языка соглашались оставить ситуацию неизменной.
В заключении можно сказать, что пп. 1...5 справедливы. Но они не являются аргументами в пользу изменения на VB.NET -> C#. А связка Delphi/Pascal -> C++ даёт более широкий диапазон знаний, большую востребованность (включая важность C++ на платформах Microsoft) и беспроблемный охват максимального количества популярных платформ: Windows, Mac OS, iOS, Android на ЕДИНОМ коде. Добавим к этому унификацию учебных материалов и единообразие среды RAD Studio XE5. Пока подход является наиболее эффективным.
Мне доставляет большое удовольствие разговор с Вами. Будучи «вне компании Embarcadero», я думал абсолютно аналогичным образом. Но сейчас, видя ситуацию изнутри, я продолжаю полностью понимать Вашу позицию, однако не могу полностью согласиться с ней.
Возможно, есть некие «обобщенные» подходы в виде «кармы». Born to be wild, natural born loser… Можно уподоблять судьбу программного продукта судьбе человека — младенчество, юность, зрелость, старость, смерть… Можно пофантазировать на тему ренессанса, ресторации или второго рождения. Всё это хорошо укладывается в формат «журнализма». Прям подмывает применить метафору, гиперболу, умеренное «передёргивание», начать задавать самому себе риторические вопросы и т.д. Главное, вовремя удержаться и не выводить дискуссию — достаточно важную — из разряда обмена профессиональными мнениями в «игру в снежки», когда мы начинаем метко швыряться друг в друга крепкими, но уже слегка подтаявшими от разгоряченных рук снежками fragментарных аргументов и фактов.
Но вернёмся на секунду к чистой полемике. Я даже не буду цепляться за отдельные фразы. Хотя, пожалуй, «отобью» Майкрософт. Нельзя так огульно клеймить корпорацию, де-факто определившую облик современной IT-цивилизации. И я сомневаюсь, что где-то есть специальный штаб, где заговорщики секретном бункере зловеще замышляют коварные планы, как умышленно испортить какой-то продукт, «убить» технологию и «подставить» разработчиков/пользователей. Извините, коллег по «цеху» я в обиду не дам. IT-вселенная так быстро меняется, общие потребительские настроения настолько непредсказуемы, технологии слишком быстро достигают верхней грани технического совершенства, что даже великие стратеги и гениальные инженеры не могут… не могут что? обеспечить линейный рост функциональности и качества. Очень быстро «идея, подающая большие надежды» становится «большим разочарованием». Если посмотреть на космическую отрасль (я полагаю, у очень многих программистов в настоящем есть родители, которые работали именно в этой сфере), то там тоже полно гениальных всплесков, тупиковых ветвей, великих катастроф, ярких прорывов и т.д. Нужно чуть более с пониманием относится к проблематике создания и развития сложных технических систем. Не создавать себе кумиров, чтобы потом в них не разочаровываться.
Теперь о Borland/Embarcadero. Был период эйфории, когда новые возможности RAD были помножены на резкий рост интереса к разработке прикладных программ. Это — не потому, что в Borland-е работали «волшебники» (хотя и это тоже). Delphi не была бы таковой, если бы не Microsoft Windows со своим API. А «паровозило» тут железо, что неудивительно. Delphi сыграла роль «автоматической коробки передач», которая очень эффективная при условии наличия автомобиля, который в современном виде невозможен без бензина, который в современном виде невозможен без определенного уровня мощности нефтедобы/перерабатывающей промышленности. В какой-то момент АКПП была предметом культа, теперь стала «полезным агрегатом», не более.
Но в момент бурного и практически лишенного альтернативы роста популярности Delphi у компании Borland были ресурсы «продолжать удивлять», а также «поражать» и даже «восхищать». Но идеологическая зависимость VCL от WinAPI сокращала поле для проявления фантазии. Такой «захватывающий» прогресс в плане добавления функциональности к средству разработки уже нельзя было поддержать, извините, никакими ресурсами. Вместо обычного станка разработчикам дали универсальный станок с ЧПУ. Дальше что? Дальше Borland продолжила исследования в смежных областях. Не было никакого умышленного «предательства интересов трудового народа».
В какой-то момент Borland начала «упираться границами» в другие средства разработки — да — Microsoft Visual Studio и Java (имея свой JBuilder, когда-то бывший сверхпопулярным). Я тогда работал тренером Delphi (и, поймите правильно, Visual Studio). В какой-то момент количество учащихся начало уменьшаться, т.к. «все уже выучились», а рост числа программистов стал коррелировать с общим ростом населения (с той же интенсивностью). Но бизнес (любой бизнес) хочет расти не «вместе с населением», а быстрее. Средства разработки стали собственностью компании Embarcadero. Первым делом (после неудачных попыток «поиграть на поле .NET» в последние годы Borland) мы постарались «отдать часть технологических долгов», стабилизировав IDE. Были сделаны различные нововведения в язык Delphi. Технология была приведена в состояние готовности для нового «скачка» возможностей. Этим и стала «мобильная революция».
Теперь общая направленность развития — мульти-платформенность. Задачи решались поэтапно — сначала Windows и Mac OS на основе единого кода. Затем iOS на платформе FireMonkey. Далее, Android. В «технологическом стеке» средств мобильной мульти-платформенной разработки Delphi занимает все более и более уверенные позиции. Это обусловлено потребностями рынка. Постепенно «классические VCL-разработчики» начинают пробовать свои силы в сфере «корпоративной мобильности» на основе годами наработанной компетенции. Игрушечная «обезьянка» стала «Платформой FM», появились наши «герои» (например, Digifort, за 2 недели реализовав iOS и Android версию своего мобильного клиента). Да, тут есть неоспоримая заслуга нашего R&D (значительная часть которого уже представлена российскими инженерами). Но это это всё явилось результатом правильной стратегии развития компании Embarcadero. У нас есть конкуренты, мы их уважаем. Но есть чем и ответить. Техническая гонка вооружений на фоне объективной рыночной реальности — вот залог развития прогресса. Так было и авиастроении, и в системах вооружения, и в других областях НТП.
Совершенно понятно, что такое соперничество, столкновение идей, подходов и реализаций не идёт «мирно и гладко». Твёрдотопливные двигатели или жидкостные? Реактивные двигатели или винтовые? Ракетное вооружение и ствольная артиллерия? Для кого-то это оборачивается личной трагедией. Для кого-то — точкой профессионального роста. Главное, отбросить эмоции и «честно забивать голы», а не кричать на трибуне «рыжего с поля».
Завершить хочу следующим позитивом. Мы сейчас проводим конкурс мобильной разработки под Android в Delphi. Количество поданных заявок приятно удивило. Особо хочется отметить студентов — они просто счастливы, что освоенная в рамках учебного процесса Delphi позволяем им реализовывать свои идеи для мобильных устройств. Скоро подведем итоги конкурса, я буду рад поделиться результатами и показать, как современный вариант Delphi с «Платформой FM» решает задачи разработки мобильных приложений на основе единого кода и для Android, и для iOS. Скоро подтягивается C++Builder для iOS, это для Pascal-haters.
Так выглядит (совершенно объективно) история Delphi. В настоящий момент она не только практически идеальная среда для обучения программированию, но и становится одним из наиболее востребованных инструментов разработки современного ПО.
Немного отвлекаясь от смешной и творческой доработки картинки, добавим серьёзности.
Речь шла о массовом обучении программированию. Здесь критерий «поиска работы» не является 100% валидным. Мы говорим о том, что ориентировка на текущие потребности рынка труда именно в профессиональной сфере не может служить основой для выбора технологии обучения.
Если посмотреть на текущие потребности, вызванные бурным ростом числа мобильных устройств, то — да — доминантой будут Java и Objective-C. Но какая доля всех школьников и всех студентов будут искать работу именно в сфере программирования? Зачем же остальных мучить Java и Objective-C?
Давайте пойдём дальше. Не надо ли в школе начать изучение Big Data?
Ещё раз прошу задуматься именно о «массовости» и «доступности». Стоит ли ради менее 1% школьников/студентов непрограммистских специальностей ставить под угрозу общий уровень понимания основ программирования? Тогда могут поднять голос биологи. Они потребуют пересмотра образования в школе типа «даешь молекулярную биологию» и «генетику» в начальных классах! Лингвисты заставят учить детей минимум 3 языка (германская группа, романская группа и какой-нибудь азиатский язык). Спортсмены попросят ввести обязательные уроки физкультуры на манер тренировки профессиональных хоккеистов 5 раз в неделю. В этом-то и смысл высшего и/или специального образования, когда уже совсем небольшая группа «затачивается» на конкретных нужды узкого сегмента рынка труда.
Тем, кому надо — да, могут после Delphi в рекордные сроки начать C++Builder в рамках специализированных программ уже в школе. Есть пример, когда в средней школе ученикам дают OpenGL и COM-технологию. Есть и спецклассы литературного профиля — они и Байрона переводят в качестве ДЗ. Но пусть Delphi/Pascal будут тем самым первым и любимым языком программирования для абсолютного большинства школьников и студентов. Сможете на этот счет картинку переделать? :)
Ссылочку плиз. Из официальных презентаций корпорации Microsoft.
>>Ей на смену в десктопных приложениях пришел WPF
Ссылочку, пожалуйста, где корпорация Microsoft рекомендует использовать WPF для разработки современных «настольных» приложений.
>>мобильные платформы и все прочее мы с вами не обсуждали.
Зато рынок «обсуждает». Степень актуальности средства разработки зависит от того, можно ли с его использованием создавать мобильные приложения для самых популярных платформ iOS и Android.
>>Вы согласны с тем, что сравнивать между собой нужно продукты одного класса, а не разных?
Вы где-то увидели сравнение каких-либо технологий, которые я приводил?
Я привёл, но только с позиции обучения программированию (это — тема статьи, извините, автор в праве выбирать тот контекст обсуждения, который указан в качестве темы).
Здесь связка Delphi (первый этап) и C++Builder (второй этап) — очень привлекательный подход для:
— охвата максимально широких масс учащихся;
— выработки актуальных знаний и навыков.
Прошу Вас, расскажите, как Вы будете учить детей на WPF разрабатывать под Windows, Mac OS, iOS и Android.
Я был на Microsoft DevConf'2011. На (о чём писал).
На слайде было (рекомендации по использованию, озвученные г-ном Черномордиковым):
— C++
— WinForms
— Silverlight
— HTML5
Что изменилось с тех пор? (см. запись трансляции Visual Studio 2013 launch):
этого слайда больше нет.
Зато есть ASP.NET + Xamarin для разработки на C# под мобильные платформы (посмотрите программу, пожалуйста, сами, она легко гуглится).
Так что — является ли WinForms «бэктрендом» для WPF, что случилось с WPF в контексте Silverlight, что у нас с «сервелатом», что рекомендует Microsoft в качестве средств разработки…
А это и было предсказуемо. .NET изначальна была «технологией одного вендора».
Есть более удачная ветка (пост) про цены/поставки — ссылка в тексте.
Бесплатная редакция отсутствует, на что есть масса причин. Но их осознание требует определённой подготовки. Итак, посмотрим, откуда берётся «бесплатные» средства разработки.
Они существуют, но причина их «бесплатности» в том, что это есть оплата «в натуральной» форме «притаскиваняи Вас на» и «приковываине Вас к» конкретной платформе. Поясню на тривиальных примерах.
— Вам дарят принтер (продают с убытком), но потом Вы пожизненно (для принтера) будете покупать картриджи определенной модели;
— Вам дарят «станок для бритья» (он не стоит инчего), но Вам придется пользоваться только определенным типом лезвий (даже в рамках отдельного бренда);
— Вам дарят средство разработки, но создавать приложения на нём Вы сможете только под определенную платформу (ОС, hardware);
— …
Последний пункт чуть сложнее, чем первые 2, т.к. схема не одноходовая. Вендор даёт Вам лицензию «бесплатно», а платит за Вашу лицензию польователь Вашей (одно-платформенной) программы, который из-за Вашей программы вынужден покупать программно-аппаратную платформу, в цену которой входит производство «беслпатного» средства разработки.
т.е. стоимость инструмента «замаскирована». Если хотите — плата за лояльность Вам.
Казалось бы — ну и славно! Есть же «халява», почему бы и не воспользоваться?!
Так то он так, так и было до момента, когда на одной платформе Windows было два сравнимых инструмента Windows-разработки: Visual Studio и Delphi. Опять же, надо понимать, что из-за практически монопольного доминирования ОС Windows прибыли корпорации Microsoft… мммм… позволяли достаточно быстро и мощно «фаршировать» студию всем, чем можно. Собственно, это и продолжает происходить.
И если Microsoft может «вбить в студию» всё, что дуже угодно — от «функционального программирования» до «ALM». Можно шпиговать разнотравьем, получая пирожок, пахнущий всем сразу. Можно сделать две платформы WPF и Silverlight, а потом прибить их обе. Вообще, Microsoft все спокойно относилась к «плохим запускам». Как в комической индустрии — всегда на долю «хороших» пусков обязательно будет доля «плохих». Вспомните Millennium, Vista. Здесь я не привожу «критику» Microsoft — великой корпорации, которая стала двигателем цивилизации на рубеже XX-XXI вв.
Но вся эта «бесплатная» монета всегда имеет и вторую сторону. Как только доминанта Microsoft была сломлена — нет, не альтернативной настольной системой, а мобильной платформой… точнее сразу 2-мя… Какой прок от бесплатной Visual Studio, если она не даёт создавать приложения под iOS и Android?
Происходит «перегазгузка» компетенций разработчиков. 10 лет C# и Visual Studio не значат ничего.
Кстати, я теперь начал догонять, почему в начале моей деятельности «старые программисты» всегда норовили мне рассказать «про перфокарты» и «машинные коды». Им было до глубине души обидно, что их навыки «заклеивания дырочек» никому не нужны, а ячейки и регистры уже давно другие, никого не парит «засунуть программу в 20 кибайт» и т.д., а p2 = (p = NULL)? ++p: p--; стало цениться больше, чем 20 опыт фортрана.
Теперь Delphi/C++Builder/RAD Studio стала мульти-платформенным средством, акции знания Delphi (C++Builder/RAD Studio) резко подскочили вверх на фоне .NET-скиллов… (кто не верит, посмотрите, сколько стоит iOS-девелопер vs .NET девелопер).
И уже с грустью в голосе Microsoft объявляет партнёрство с Xamarin (сами не могут поддерживать Android и iOS, хотя чисто технически для Microsoft сделать «ms android native studio» проблем не представляет). Всё это к тому, что «прося бесплатный турбо эксплорер» нужно представлять себе причины существования оного в прошлом, доступности Visual Studio Express сегодня, а также проблему «соскакивания» с тулзы или «перезагрузки» компетенации в будущем.
Если есть желание дальше обсудить — welcome. Только давайте не «стоя лбом к стенке», а сделав два шага назад, чтобы видеть всю картину целиком. Кстати, рад буду рассказать и дальше, особенно в контексте «Samsung Android Studio», выхода Tizen, фрагментации рынка мобильных платформ, доли рынка Microsoft в мобильных системах (несмотря на бесплатность Visual Studio Express… извините, не удержался).
Дело в том, что я работал «чистым технарём». Вопросы маркетинга, продвижения, «первой дозы бесплатно» меня мало интересовали, а также доступа к данным не было. Сейчас же у меня больше времени на «осмысление картины в целом». Конечно, хочется ответить на вопрос «бесплатности» лицензий на RAD Studio как «дяди не понимают что-то». К сожалению, это не так, а «дяди готовы объяснить, как мир устроен».
Считайте, что стоимость лицензии на RAD Studio — это цена свободы. Вы не обязаны писать для Windows. Или для Mac OS. Или iOS. Или Android. Свобода того стоит, даже если просто пересчитать стоимость ведения 4 отдельных проектов под 4 разных платформы.
>>>>Я всего лишь сказал, что UML вполне себе ценен и без кодогенерации.
>>Вы утверждаете обратное?
Где? Найдите хоть одно место, где «я» что-то утверждал. Любите Discover «discovery how it's made»? Ну вот я сделал то же самое. «Мысленно» пришёл в Гарант и походил с камерой, «поснимал» (на мозг) то, как Максим и Александр используют UML в процессе производства ПО. Позадавал вопросы — «зачем»? Вообще ничего не утверждал. Вполне убедился, что UML без кодогенерации не так эффективен, как с кодогенерацией. Не очень понял, почему Вы на это обиделись?
>>Но практической полезности от факта, что кто-то где-то внедрил такой инструмент и процесс — ноль целых, ноль десятых.
Это — очень интересная мысль. Кстати, попробуйте на досуге написать диссертацию. Если (по профилю) Вам 40 лет — то самое время. Вашим профессиональным склонностям вполне подойдёт инженерная специализация. 40 лет — расцвет творческих способностей, когда человек еще не совсем перешёл на руководящие позиции (отстал от жизни), но уже имеет огромный опыт и компетенцию.
Кстати, могу поработать Вашим консультантом. Часто «мной пользовались», чтобы сформулировать тему: предмет, объект, рамки исследования. Цель и задачи. Так вот, без «внедрения» Вам не получить доказательство полезности. А без доказательства полезности, исследования бесполезны. Если бесполезны — то не востребованы. Поэтому факт внедрения UML (определенным способом) является ценнейшим наблюдением. Именно это — обогащение базы знаний человечества, к чему любой преосвященный человек и должен стремиться.
>>Я не спорю, что иметь синхронизированные модель и код может быть полезно, если это не несёт существенных накладных расходов.
А какая польза иметь «рассинхронизированную» модель и код?
>>Вы, извините, за прямоту, уже второй раз тут пукнули в лужу показываете себя не с лучшей стороны.
Весьма занимательный ассоциативный ряд. Не скажу, что очень оригинальный случай, но вполне показательный.
>>Во-первых, какая анонимность на хабре? Загляните в профиль.
Открываем профиль. 11681-й в рейтинге хабралюдей. Ну, хорошо, что не 11682-ой. Уже что-то.
Где а) компания б) проекты в) скрин-шоты работ? Пока только 11681.
Да, что-то я стал сдавать. Бился с №11681 на Хабре…
>>Во-вторых, я не мог даже предположить, что вас настолько заденет то, что вы для меня являетесь меньшим авторитетом, чем признанные эксперты, авторы методологий и многих, многократно переизданных и переведённых книг.
Меня задел только Ваш переход на личности. Вы, конечно, можете извиниться.
Я приму Ваши извинения.
>>В личном общении вы так же обращаетесь к собеседнику, или только когда морда в безопасности в интернете?
Не переоцените Ваши возможности. Говорю это Вам это совершенно серьезно.
>>Заметьте, вы наехали почти на всех комментаторов к статье.
Нужно за слова свои отвечать. Никогда не поздно. Даже в 40 лет.
Ну, раз так, давайте ругаться. Не люблю я это дело — переходить на личности, но иногда того требует. Нельзя же лечить болезнь вне конкретного больного? Здесь-то хоть со мной согласны? Хорошо!
>>Ну, 3 — это ваше частное мнение.
Ну — хотя бы это «групповое» мнение с привлечением экспертов из «Гаранта». Чтобы это не смотрелось, что я прикрываюсь чужим (заметьте — не книжным, а авторитетом реального большого лидирующего IT-проекта), позволю себе объясниться.
UML без кодогенерации означает, что есть код (если он есть, а это не просто «рисовалово»), а есть диаграммы. Давайте обощим — не диаграммы, а «документация». Чертёж. Если у Вас нет строгой синхронизации (о чём, кстати, написано выше), то рано или поздно будет расхождение. Для программиста код всегда будет важнее документации к нему (даже отбрасывая идею о «самодокументируемости» кода), поэтому, когда настанет черёд выбирать, UML за ненужностью будет отброшен.
Или же Вам придётся постоянно под код подгонять UML, что порочно. Здесь же и появляется идея о запрете на «реверс».
>> Про 1 и 2, вы бы поинтересовались сначала, а то некрасиво.
Я знакомился с UML по первоисточникам. А также по документации к программным средствам моделирования на UML. Зачем мне учебник из серии «для чайников»?
Опять же — Ваш любимый Фаулер. Редкостный халтурщик, если судить по его тонюсенькой книге про UML.
>>Ларман и вот эти люди ниже для меня более авторитетны.
Как авторы книжек для детишек? UML в комиксах?
>>Хотя бы потому, что их труды и достижения я знаю, а ваши пока не попадались.
Переходим к главному. Сейчас будет немного больно.
1. Вы позволили себе перейти на личность, что, само по себе возмутительно. Пользуетесь анонимной безответственностью. Трусливо, но понятно.
2. Когда Вы задаёте такой вопрос, будьте готовы представить Ваши достижения. Кроме троллинга и умением пользоваться google seach по строке «UML books».
3. Ну и главное!
>>а ваши пока не попадались.
Вы просто не там искали.
Посмотрите диссертации за последние 5 лет на тему «применение искусственного интеллекта для построения предметно-ориентированной САПР».
А какую диссертацию написали Вы?
>>Даже обсуждать не хочется.
Какая незадача! Так быстро признать поражение…
>>И заметьте, я не критикую ваш подход.
Потому что не можете. Чего-там не хватает. Опыта? Знаний? Одного темперамента мало!
>>у меня мало о нём информации.
Так спрашивайте! Александр и Максим не оставили ни одного вопроса неотвеченным!
>>Так что не надо на меня нападать.
А это Вы уже с зеркалом разговариваете. Кому Вы нужны, чтобы на Вас нападать?
Может, что-нибудь из своих трудов дадите почитать. Лерман Мартинович Фаулер, Вы наш, непризнанный.
Пока кроме достаточно бедненького списка литературы ничего не представили. Про UML, конечно.
Ну а так — я вполне подозреваю, что Вы — вполне успешный профессионал. Разве что манер маловато. Но это, как обычно
>>ну значит это мои проблемы :)
Ну а теперь, когда Вы всё это прочитали и слегка покраснели от негодования, прочитайте уж и это (до кучи).
Я искренне извиняюсь за причиненную Вам обиду. Совершенно искренне. Не сомневаюсь, что у Вас действительно развитый интеллект и большой талант к программированию. Возможно, нам было бы приятно в дальнейшем общаться, если эта наша размолвка не повлияет на дальнейшее Ваше миропонимание.
Честно скажу, стыдно, когда взрослые люди как-то ругаются из-за пустяков.
1. В книге есть пример РЕАЛЬНОГО применения в реальной компании при создании и развитии реального продукта? А то получится — «гладко было на бумаге».
2. Про «классиков» в интервью есть отдельная тема. Если Ларман не является действующим разработчиком, то он — классик.
3. «Без кодогенерации» — первая и главная ошибка, если её сделал Ларман, а не Ваша интерпретация.
4.
>>Извлечённые знания в инженерии затем структурируют.
И какая же структуризация «знаний» в терминологии ИИ используется в книге Лармана?
В «инженерии знаний» техника «вопрос-ответ» (интервью) есть один из способов извлечения (собственно) знаний из экспертов. Если знания нечёткие, слабоформализуемые, местами — да — содержащие противоречия, то диалог по-сути единственный метод. Это характерно для многих подобных областей — от политики и экономики до сферы искусства. Даже философы очень часто использовали форму диалога для а) генерации б) извлечения в) представления знаний. И нельзя не вспомнить классический тест на решение задачи создания искусственного интеллекта, когда факт наличия которого определялся на основе невозможности отличить человека от машины при задании последней вопросов и анализе ответов.
В заголовке статьи фигурирует слово «зачем», а не «что такое» или «как надо». Это и есть основная цель статьи — закрыть пробел в (общечеловеческих) знаниях, именно «зачем» нужен UML.
У меня — «чесалось». Но я НЕ МОГУ не УПОМЯНУТЬ — Кирилла Пугина — как одного из разработчиков генератора… Это было бы — нечестно… Он сейчас не с нами, и работает в MicroSoft. Но мы БЛАГОДАРНЫ ему за реализацию САМЫХ «хардкорных» вещей. Спасибо — что он был с нами.
Просто если вы думаете, что мы «слабали эту статью на коленке».
То поверьте — вы СИЛЬНО ошибаетесь… Мы ДОЛГО работали над ней… И многое из неё выкинули… По разным соображениям… И СОГЛАСОВЫВАЛИ это с работодателем… Что — ПОВЕРЬТЕ — для программистов — НЕПРОСТО…
Так что это «не на коленке» и «не джинса»…
Неинтересно — не читайте… Что делать…
Интересно — пишите… Не интересно — жаль… Значит мы недоработали…
В до-FireMonkey-овский период были стремления Embarcadero сделать библиотеку визуальных компонентов, выходящую за рамки Windows. Совсем углубляться в историю с CLX сейчас смысла большого нет. Тогда тоже были «кроссплатформенные» инициативы, вызванные рыночной ситуацией (Linux в предустанове шёл практически на каждом втором ноутбуке — ну или по крайней мере был заметен в качестве бизнес-настольной ОС — не путать с «вашей» домашней настольной ОС — разные вещи). Почему Linux не стал «альтернативой» — вопрос очень интересный. Факт более высокой стоимости владения? Маркетинговый разгром? Предчувствие облаков и снижение интереса к настольным баталиям? Стоимость Windows-компетенции сисадмина vs «Линуксоида»? Протекционизм? Возьмём узкий сегмент — школы. Деньги экономит школа/гос-во, а напрягаюсь я (учитель). Хотя есть и специалисты с опытом (не) успешного распространения Linux, которые, возможно, захотят пролить бОльший свет, хотя общая тема здесь другая.
Закончу лишь тем, что Kylix до сих пор продаётся/используется.
К релизу Delphi XE назрела необходимость сделать что-то новое. Если компания (от поставщика йогуртов до автопрома) не выдаёт ежегодно что-то новое (желательно революционное), то начинаются здоровые сомнения в её (блин) креативных возможностях. А имиджевая составляющая в IT (какими бы функциональными прагматиками мы, разработчики/пользователи, себя бы не считали) очень высока. Можно сказать, выше не бывает, т.к. мне продают функционал, полезность которого я могу оценить только в перспективе, а чем выше уровень технического совершенства, тем дальше эта перспектива. А тут нам (Embarcadero) хорошо поддал рынок с 16% доли Mac-ов в корпорациях США и хорошим ростом на фоне стагнации десктопных Windows-машин. Было принято решение сделать VCL+ и ей-же войти в новый сегмент средств разработки под Mac OS.
VCL+ была хорошей идеей, Mac OS с хорошей имиджевой составляющей особенно в контексте ЛПР в нашем случае «двигал» средства разработки за собой (хотя, в большинстве случаев, бывает и наоборот). Перед инженерами Embarcadero встала задача разделения VCL на функционально-поведенческий и визуализационный уровень. Пилёжка VCL оказалась чуть сложнее, чем распиливание барышень в ящике, WinAPI слишком жёстко был прописан в генах этой библиотеки (что ранее как раз и было громадным её преимуществам, качество визуальных приложений на её основе не уступало «нативным» тулзам). Создавать «Delphi for MacOS» с полностью различными исходниками относительно классических «Delphi for Windows» было плохой идеей – биться сразу на двух фронтах (с Visual Studio и с Xcode) Embarcadero явно не улыбалось.
Выло выбрано следующее стратегическое решение. Слово «стратегический» здесь нужно воспринимать неэмоционально. Просто «стратегия» означает – линия поведения в ситуации неопределенности – такова стратегия IT-рынка средств разработки. Вместо деления VCL с весьма сомнительными перспективами в плане совместимости со «старыми» VCL-неразделёнными кодами, компания Embarcadero решила взять новую библиотеку. Да, она в прототипе основывалась на KSDev с последующим развитием и ре-брендингом в FireMonkey (сейчас «платформа FM»).
FireMonkey изначально основывалась на единстве функционального поведения (кнопка нажимается, «поле ввода» получает символы, чекбокс – чекится), при вариациях механизмов отображения – Quartz для Mac OS и DirectX (и GDI+) для Windows. Тут и проявлен «исторический» аспект «не-нативности» контролов FireMonkey. Уже были известны библиотеки, «рендерящие» в GPU-based режиме. Для Mac OS это вообще не было проблемой, а хилые Windows-машины оставались на откуп общей генеральной линии развития аппаратного обеспечения компаний (GDI+ был оставлен именно по этой причине). Вышла Delphi XE2, которая включала не только VCL практически без изменений, но и новую библиотеку кроссплатформенной разработки на основе единого кода FireMonkey.
Технология дала основу для достаточно вменяемого и, как оказалось, эффективного маркетинга.
— VCL forever – весь legacy-код будет эффективен и работоспособен;
— Delphi готова к освоению новых платформ.
В довесок Embarcadero усилила инструмент 64-битным компилятором и занесла ногу на поле iOS. В релизе XE2 можно было создавать «нативные» приложения для iOS с использованием той же самой FireMonkey. Object Pascal – он и в Африке такой (в буквальном смысле этого слова, в ЮАР принята гос-программа обучения на Delphi), а рендеринг/отображение компонентов сводится к элементарным операциям отрисовки графических примитивов.
Технологически – функциональность визуальных компонентов неизменна, под конкретную платформу на уровне сервисов подключается «аппарат рисования». Конечно, это – не «нативные» конторы. Зато интерфейс был 100% единый кроссплатформенный на уровне дизайнера Delphi.
Рынок отреагировал на это ростом более 50% продаж средств разработки Embarcadero поколения XE2. Разработчикам – пользователям Delphi – очень понравилась идея сохранения компетенции в современных динамически изменяющихся условиях в сфере платформ. Маркетингово это звучит как one «codebase – one team – one project schedule». Проблема «нативности» контролов никого не парила – поверьте, большинству разработчиков важны интегральные качества инструмента разработки, а не мифическая близость к платформе. В целом, идея хорошо проинвестированной технологии быстро вылилась в растущий имидж Delphi, сказалась на росте и послужила основой дальнейшего развития.
Если в области Windows-desktop-client-server-rich-GUI-разработки Delphi начинала с тотальной монополизации, то вход в рынок средств мобильной разработки требовал сверхусилий. VCL оставлена была «как есть» из-за невозможности четкого выделения границ функциональности/отображения. А без этого всё-равно получалась не «новая VCL с нативным отображение», а «ещё одна VCL для Mac OS» или iOS или Android и т.д. Достаточно дерзкая попытка взять iOS из Delphi XE2 при помощи конвертации проекта в Xcode и до-компилирования Free Pascal Compiler для ARM удалась. Но полноценное решение появилось в Delphi XE4 на основе своего компилятора и полного отказа от Xcode.
Возвращаясь к теме дискуссии – «нужны ли нам нативные контролы в противовес рисованными руками»? Ещё раз хочется подчеркнуть, что тема – не чисто технологическая. Любое инженерное решение должно основываться на комплексе показателей. Но есть же средства мульти-платформенной разработки, которые используют нативные конторлы? Да, есть, но они не идеальны. Сохранение единства кода и дизайна интерфейса сильно под вопросом. В смысле, что вопроса то и нет, т.к. нет единства. Есть «скриптовики» и «гибридные» средства. Но нативный исполняемый код и нативный интерфейс при 100% едином исходном коде – это проблема, которая должна быть решена. Подход Embarcadero в том, чтобы (возможно) придти к «нативному» решению от «рисованного», тогда как можно было тормознуть релизы (XE4 – iOS и XE5 – Android), чтобы «впилить лобзиком» нативные контролы в FireMonkey.
Чуть коснёмся проблематики FM vs VCL (и далее “VCL.mobile” – мне вполне нравится это название). Когда вводили новую библиотеку FireMonkey, конечно, был вопрос. Сделать их максимально близкими для облегчения миграции (хотя бы на уровне свойств-событий) или сбросить оковы «совместимости». Пошли вторым путём, FM сильно отличается от VCL. Победителей не судят, а мессидж «FireMonkey – не VCL» был воспринят спокойно. Все-таки кроссплатформенный (и далее мобильный) проект обычно новый и мало тащит за собой коды прошлых desktop-проектов.
Нативизация – проблемы и задачи.
Не-нативность (рисованность) контролов FM дала гигантское ускорение. Для покрытия новой платформы потребовалось лишь создать новый платформенный стиль (чуть больше, чем просто «шкурка» или «скин»). Это дало возможность в 2013 году обеспечить поддержку и iOS, и Android. Некоторые «особо злые в плане само-рисования» контролы уже нативные («календарчик», к примеру).
Нужна ли FM истинная нативность? Вопрос реакции пользователей (разработчиков мобильных приложений). Пока наблюдается достаточно ярко выраженная реакция что: «наконец-то Delphi делает под Android/iOS» с весьма весомым притоком пользователей Visual Studio и Xcode в ряды «дельфистов». Скорее всего, задачей будет в первую очередь дальшейшая стабилизация как платформы FM, так и IDE в целом, а нативизация будет там, где она критична. По крайней мере на ближайшую перспективу, о чём было сказано при обсуждении roadmap выше.
Да, платформа FM делается российскими разработчиками, но не только ими. Вообще, сложно разделить производственные подразделения компании на «Россию» и «не-Россию».
Самое эффективное — описывать баги на qc.embarcadero.com, т.к. это есть прямой путь. Есть хорошие новости — в ближайшем roadmap обозначены явные намерения сделать технологию более стабильной (ссылка не вставляется, но edn.embarcadero.com/article/43677).
>>Я тоже писал приложение на конкурс, калькулятор с возможностью строить графики.
Компонент TChart вполне применим, на Nexux 7 мне удавалось воспроизвести достаточно насыщенные построения графиков.
>>но на телефоне получил ужасные тормоза в функции
Печально читать, но в ближайшее время мы озабочены проблемами стабильности и быстродействия (см. roadmap). Надеемся, что в ближайшее время большинство проблем будут устранены.
Спасибо за проведённые исследования. Если Вам удалось наловить ошибок, пожалуйста, создайте на них отчёт в qc.embarcadero.com, так они гораздо быстрее будут рассмотрены инженерами по качеству.
Что касается AppMethod — да, это «подвид» Delphi для новых не-дельфи-пользователей.
Язык теперь называется Object Pascal.
Сама IDE претерпела некоторые изменения косметического характера, т.к. базовый функционал IDE не требовал каких-то особых доработок при переходе от «настольной» к «мобильной» разработке.
Что касается «трудновоспроизводимых» глюков.
Бывает, что от аппарату к аппарату состав и переодичность багов меняется. У нас есть список рекомендованных устройств:
docwiki.embarcadero.com/RADStudio/XE5/en/Android_Devices_Supported_for_Application_Development
Я провожу неформальный опрос по устрйоствам
blogs.embarcadero.com/vsevolodleonov/category/android-devices/
Проведенный конкурс www.delphimobile.ru/ показал, что в широком диапазоне приложений (19 поданных проектов) Delphi for Android вполне работоспособна как инструмент создания приложений.
Процесс фиксации багов — нужно понимать — требует времени и помощи со стороны пользователей. Т.е. запощивания ошибок на qc.embarcadero.com, который — поверьте — очень внимательно прорабатывается.
Скажу так — по результатам неформального общения с участниками конкурса я также сформировал кумулятивный wish-list, который передал инженерам и который будет «исполнет» в ближайшее время.
Что же до AppMethod — да, это Delphi минус VCL.
Для корпоративных разработчиков останется «старая-добрая Дельфи» со всеми-всеми возможностями (настольная + мобильная разработка).
Для «индивидуальных» разработчиков будет реализовываться «новый-злой Аппметод» с удобными и доступными вариантами приобретения, ориентированными на быструю окупаемость лицензии за счёт продаж продукта через магазины приложений.
Да, Вы — абсолютно правы, есть досадные ошибки, но в целом технологическое ядро (для Delphi и AppMethod) в контексте мобильной разработки вполне эффективно. Остальное — дело эволюции и стабилизации продуктов, чем усиленно занимается Embarcadero в последнее время!
С уважением,
Всеволод Леонов
Developer Evangelist
Embarcadero Technologies,
Russia and CIS
Если в противопоставлении схемы обучения
Delphi — C++
нам предъявляется
VB.NET — C#
то появляется возможность перевести дискуссию в более-менее осмысленное русло, что позволяет говорить предметно.
VB.NET при достаточно спорном заявлении о «большей доступности, нежели Delphi/Pascal» в силу исторических обоснований самого факта своего появления не является языком профессиональной разработки. С одной стороны, можно достаточно уверенно поставить знак равенства между C# и VB.NET. С другой — в эпоху массового перехода на платформу .NET я не могу привести примеров, когда программисты выбирали VB.NET, а не C#. В России мне такие примеры неизвестны, хотя, в частности, в США еще в до-дотнетовскую эпоху VB считался вполне приемлемой компетенцией в плане зарабатывания денег. Хотя и здесь можно говорить о «попсовости» C#/.NET, т.к. сама корпорация Microsoft при разработкt программного обеспечения «на продажу» использовала и использует другие технологии разработки. В России в профессиональной среде VB.NET вызывал недоумение, а любой «изолированно-само-обучившийся» VB.NET-у специалист при первом же трудоустройстве пересаживался на C#.
Это подтверждает тезис, что языковая группа Visual Basic всегда была менее профессионально-пригодной, чем Delphi/Pascal.
Двинемся дальше в сторону обоснования миграции с VB.NET на C#. VB.NET настолько «подобен» C# (см. п. 2 выше), что качественного роста и расширения сферы познаний в области языковых средств для разработки ПО такой переход не даст. Приведу аналогию:
изучение VB.NET и переход на C# с точки зрения лингвистики весьма близко иллюстрируется началом изучения первого иностранного языка — испанского, а затем переход на португальский. Или из русского в украинский. Слишком близка грамматика и слишком родственны корни в силу технологического базиса (.NET).
Но является ли C# сам по себе универсальным? Давайте посмотрим на программу прошедшей конференции Microsoft www.msdevcon.ru/2013/schedule доклад F01. Там была попытка «увести» разработчиков от C# в мир С++, что не является безболезненным. Можно ли доверять C#, если сама Microsoft в общении с разработчиками как минимум не демонстрирует уверенности. Еще раз хочу напомнить конференцию Microsoft DevCon 2011, где явственно присутствовал C++ в качестве рекомендованных языковых средств.
На выходе мы имеем:
— VB(.NET) менее «профессионален», чем Delphi/Pascal при соизмеримой простоте в плане освоения;
— C#(.NET) менее востребован, чем C++ в плане широты охвата платформ, включая же платформы Microsoft.
Поясню диаграммой:
[0-уровень] --->---------->-------------> [профессиональный уровень]
Visual Basic --->----------->------------ C#
Delphi/Pascal ---->----------->------------>--------------С++
Работа по первой схеме учащиеся получать меньше, чем по второй.
В завершении немного о «кроссплатформенности» C#. Да, Xamarin даёт возможность использовать C# для программирования под iOS и Android. Но во-первых, единство исходного кода всего проекта для одновременной поддержки нескольких платформ требует работы, работы и еще раз работы. Во-вторых, инструмент Xamarin пока решает достаточно понятные прагматичные задачи, а их «ценник» выглядит более, чем впечатляющим. Здесь ценовая политика никак не коррелирует с «материнской средой» Visual Studio по очень понятным соображениям.
Разработка под Windows Phone в плоскости бесплатного использования Visual Studio, конечно, важна, но не на столько, чтобы говорить серьёзно с учётом распространенности этой платформы, включая учащихся и преподавателей. Опять же — учитывая имидж Windows Phone в молодёжной среде.
По части наличия других сред и реализаций языков — тут нужно учитывать специфику образовательного сегмента. Это и учебно-методические материалы, унификация которых в масштабах страны есть задача приоритетная. Это и сами затраты (как в денежном выражении, так и в виде человеко-часов), которые преподаватели Delphi/Pascal должны потратить на переход на другой язык по абсолютно непонятным причинам). В качестве примера могу дать следующее. В некоторых государствах в силу исторических причин обучение определенным предметам в школах/среднеспециальных/высших учебных заведениях велось на русском языке. Смена русского языка на другой, пусть даже и национальный, ведет за собой необходимость переписать и переиздать все учебники. Даже ярые противники русского языка соглашались оставить ситуацию неизменной.
В заключении можно сказать, что пп. 1...5 справедливы. Но они не являются аргументами в пользу изменения на VB.NET -> C#. А связка Delphi/Pascal -> C++ даёт более широкий диапазон знаний, большую востребованность (включая важность C++ на платформах Microsoft) и беспроблемный охват максимального количества популярных платформ: Windows, Mac OS, iOS, Android на ЕДИНОМ коде. Добавим к этому унификацию учебных материалов и единообразие среды RAD Studio XE5. Пока подход является наиболее эффективным.
Возможно, есть некие «обобщенные» подходы в виде «кармы». Born to be wild, natural born loser… Можно уподоблять судьбу программного продукта судьбе человека — младенчество, юность, зрелость, старость, смерть… Можно пофантазировать на тему ренессанса, ресторации или второго рождения. Всё это хорошо укладывается в формат «журнализма». Прям подмывает применить метафору, гиперболу, умеренное «передёргивание», начать задавать самому себе риторические вопросы и т.д. Главное, вовремя удержаться и не выводить дискуссию — достаточно важную — из разряда обмена профессиональными мнениями в «игру в снежки», когда мы начинаем метко швыряться друг в друга крепкими, но уже слегка подтаявшими от разгоряченных рук снежками fragментарных аргументов и фактов.
Но вернёмся на секунду к чистой полемике. Я даже не буду цепляться за отдельные фразы. Хотя, пожалуй, «отобью» Майкрософт. Нельзя так огульно клеймить корпорацию, де-факто определившую облик современной IT-цивилизации. И я сомневаюсь, что где-то есть специальный штаб, где заговорщики секретном бункере зловеще замышляют коварные планы, как умышленно испортить какой-то продукт, «убить» технологию и «подставить» разработчиков/пользователей. Извините, коллег по «цеху» я в обиду не дам. IT-вселенная так быстро меняется, общие потребительские настроения настолько непредсказуемы, технологии слишком быстро достигают верхней грани технического совершенства, что даже великие стратеги и гениальные инженеры не могут… не могут что? обеспечить линейный рост функциональности и качества. Очень быстро «идея, подающая большие надежды» становится «большим разочарованием». Если посмотреть на космическую отрасль (я полагаю, у очень многих программистов в настоящем есть родители, которые работали именно в этой сфере), то там тоже полно гениальных всплесков, тупиковых ветвей, великих катастроф, ярких прорывов и т.д. Нужно чуть более с пониманием относится к проблематике создания и развития сложных технических систем. Не создавать себе кумиров, чтобы потом в них не разочаровываться.
Теперь о Borland/Embarcadero. Был период эйфории, когда новые возможности RAD были помножены на резкий рост интереса к разработке прикладных программ. Это — не потому, что в Borland-е работали «волшебники» (хотя и это тоже). Delphi не была бы таковой, если бы не Microsoft Windows со своим API. А «паровозило» тут железо, что неудивительно. Delphi сыграла роль «автоматической коробки передач», которая очень эффективная при условии наличия автомобиля, который в современном виде невозможен без бензина, который в современном виде невозможен без определенного уровня мощности нефтедобы/перерабатывающей промышленности. В какой-то момент АКПП была предметом культа, теперь стала «полезным агрегатом», не более.
Но в момент бурного и практически лишенного альтернативы роста популярности Delphi у компании Borland были ресурсы «продолжать удивлять», а также «поражать» и даже «восхищать». Но идеологическая зависимость VCL от WinAPI сокращала поле для проявления фантазии. Такой «захватывающий» прогресс в плане добавления функциональности к средству разработки уже нельзя было поддержать, извините, никакими ресурсами. Вместо обычного станка разработчикам дали универсальный станок с ЧПУ. Дальше что? Дальше Borland продолжила исследования в смежных областях. Не было никакого умышленного «предательства интересов трудового народа».
В какой-то момент Borland начала «упираться границами» в другие средства разработки — да — Microsoft Visual Studio и Java (имея свой JBuilder, когда-то бывший сверхпопулярным). Я тогда работал тренером Delphi (и, поймите правильно, Visual Studio). В какой-то момент количество учащихся начало уменьшаться, т.к. «все уже выучились», а рост числа программистов стал коррелировать с общим ростом населения (с той же интенсивностью). Но бизнес (любой бизнес) хочет расти не «вместе с населением», а быстрее. Средства разработки стали собственностью компании Embarcadero. Первым делом (после неудачных попыток «поиграть на поле .NET» в последние годы Borland) мы постарались «отдать часть технологических долгов», стабилизировав IDE. Были сделаны различные нововведения в язык Delphi. Технология была приведена в состояние готовности для нового «скачка» возможностей. Этим и стала «мобильная революция».
Теперь общая направленность развития — мульти-платформенность. Задачи решались поэтапно — сначала Windows и Mac OS на основе единого кода. Затем iOS на платформе FireMonkey. Далее, Android. В «технологическом стеке» средств мобильной мульти-платформенной разработки Delphi занимает все более и более уверенные позиции. Это обусловлено потребностями рынка. Постепенно «классические VCL-разработчики» начинают пробовать свои силы в сфере «корпоративной мобильности» на основе годами наработанной компетенции. Игрушечная «обезьянка» стала «Платформой FM», появились наши «герои» (например, Digifort, за 2 недели реализовав iOS и Android версию своего мобильного клиента). Да, тут есть неоспоримая заслуга нашего R&D (значительная часть которого уже представлена российскими инженерами). Но это это всё явилось результатом правильной стратегии развития компании Embarcadero. У нас есть конкуренты, мы их уважаем. Но есть чем и ответить. Техническая гонка вооружений на фоне объективной рыночной реальности — вот залог развития прогресса. Так было и авиастроении, и в системах вооружения, и в других областях НТП.
Совершенно понятно, что такое соперничество, столкновение идей, подходов и реализаций не идёт «мирно и гладко». Твёрдотопливные двигатели или жидкостные? Реактивные двигатели или винтовые? Ракетное вооружение и ствольная артиллерия? Для кого-то это оборачивается личной трагедией. Для кого-то — точкой профессионального роста. Главное, отбросить эмоции и «честно забивать голы», а не кричать на трибуне «рыжего с поля».
Завершить хочу следующим позитивом. Мы сейчас проводим конкурс мобильной разработки под Android в Delphi. Количество поданных заявок приятно удивило. Особо хочется отметить студентов — они просто счастливы, что освоенная в рамках учебного процесса Delphi позволяем им реализовывать свои идеи для мобильных устройств. Скоро подведем итоги конкурса, я буду рад поделиться результатами и показать, как современный вариант Delphi с «Платформой FM» решает задачи разработки мобильных приложений на основе единого кода и для Android, и для iOS. Скоро подтягивается C++Builder для iOS, это для Pascal-haters.
Так выглядит (совершенно объективно) история Delphi. В настоящий момент она не только практически идеальная среда для обучения программированию, но и становится одним из наиболее востребованных инструментов разработки современного ПО.
Немного отвлекаясь от смешной и творческой доработки картинки, добавим серьёзности.
Речь шла о массовом обучении программированию. Здесь критерий «поиска работы» не является 100% валидным. Мы говорим о том, что ориентировка на текущие потребности рынка труда именно в профессиональной сфере не может служить основой для выбора технологии обучения.
Если посмотреть на текущие потребности, вызванные бурным ростом числа мобильных устройств, то — да — доминантой будут Java и Objective-C. Но какая доля всех школьников и всех студентов будут искать работу именно в сфере программирования? Зачем же остальных мучить Java и Objective-C?
Давайте пойдём дальше. Не надо ли в школе начать изучение Big Data?
Ещё раз прошу задуматься именно о «массовости» и «доступности». Стоит ли ради менее 1% школьников/студентов непрограммистских специальностей ставить под угрозу общий уровень понимания основ программирования? Тогда могут поднять голос биологи. Они потребуют пересмотра образования в школе типа «даешь молекулярную биологию» и «генетику» в начальных классах! Лингвисты заставят учить детей минимум 3 языка (германская группа, романская группа и какой-нибудь азиатский язык). Спортсмены попросят ввести обязательные уроки физкультуры на манер тренировки профессиональных хоккеистов 5 раз в неделю. В этом-то и смысл высшего и/или специального образования, когда уже совсем небольшая группа «затачивается» на конкретных нужды узкого сегмента рынка труда.
Тем, кому надо — да, могут после Delphi в рекордные сроки начать C++Builder в рамках специализированных программ уже в школе. Есть пример, когда в средней школе ученикам дают OpenGL и COM-технологию. Есть и спецклассы литературного профиля — они и Байрона переводят в качестве ДЗ. Но пусть Delphi/Pascal будут тем самым первым и любимым языком программирования для абсолютного большинства школьников и студентов. Сможете на этот счет картинку переделать? :)
Ссылочку плиз. Из официальных презентаций корпорации Microsoft.
>>Ей на смену в десктопных приложениях пришел WPF
Ссылочку, пожалуйста, где корпорация Microsoft рекомендует использовать WPF для разработки современных «настольных» приложений.
>>мобильные платформы и все прочее мы с вами не обсуждали.
Зато рынок «обсуждает». Степень актуальности средства разработки зависит от того, можно ли с его использованием создавать мобильные приложения для самых популярных платформ iOS и Android.
>>Вы согласны с тем, что сравнивать между собой нужно продукты одного класса, а не разных?
Вы где-то увидели сравнение каких-либо технологий, которые я приводил?
Я привёл, но только с позиции обучения программированию (это — тема статьи, извините, автор в праве выбирать тот контекст обсуждения, который указан в качестве темы).
Здесь связка Delphi (первый этап) и C++Builder (второй этап) — очень привлекательный подход для:
— охвата максимально широких масс учащихся;
— выработки актуальных знаний и навыков.
Прошу Вас, расскажите, как Вы будете учить детей на WPF разрабатывать под Windows, Mac OS, iOS и Android.
Я был на Microsoft DevConf'2011. На (о чём писал).
На слайде было (рекомендации по использованию, озвученные г-ном Черномордиковым):
— C++
— WinForms
— Silverlight
— HTML5
Что изменилось с тех пор? (см. запись трансляции Visual Studio 2013 launch):
этого слайда больше нет.
Зато есть ASP.NET + Xamarin для разработки на C# под мобильные платформы (посмотрите программу, пожалуйста, сами, она легко гуглится).
Так что — является ли WinForms «бэктрендом» для WPF, что случилось с WPF в контексте Silverlight, что у нас с «сервелатом», что рекомендует Microsoft в качестве средств разработки…
А это и было предсказуемо. .NET изначальна была «технологией одного вендора».
Бесплатная редакция отсутствует, на что есть масса причин. Но их осознание требует определённой подготовки. Итак, посмотрим, откуда берётся «бесплатные» средства разработки.
Они существуют, но причина их «бесплатности» в том, что это есть оплата «в натуральной» форме «притаскиваняи Вас на» и «приковываине Вас к» конкретной платформе. Поясню на тривиальных примерах.
— Вам дарят принтер (продают с убытком), но потом Вы пожизненно (для принтера) будете покупать картриджи определенной модели;
— Вам дарят «станок для бритья» (он не стоит инчего), но Вам придется пользоваться только определенным типом лезвий (даже в рамках отдельного бренда);
— Вам дарят средство разработки, но создавать приложения на нём Вы сможете только под определенную платформу (ОС, hardware);
— …
Последний пункт чуть сложнее, чем первые 2, т.к. схема не одноходовая. Вендор даёт Вам лицензию «бесплатно», а платит за Вашу лицензию польователь Вашей (одно-платформенной) программы, который из-за Вашей программы вынужден покупать программно-аппаратную платформу, в цену которой входит производство «беслпатного» средства разработки.
Давайте формульно:
Ц_продажная_платформы = Ц_платформы + Ц_средства_разработки;
т.е. стоимость инструмента «замаскирована». Если хотите — плата за лояльность Вам.
Казалось бы — ну и славно! Есть же «халява», почему бы и не воспользоваться?!
Так то он так, так и было до момента, когда на одной платформе Windows было два сравнимых инструмента Windows-разработки: Visual Studio и Delphi. Опять же, надо понимать, что из-за практически монопольного доминирования ОС Windows прибыли корпорации Microsoft… мммм… позволяли достаточно быстро и мощно «фаршировать» студию всем, чем можно. Собственно, это и продолжает происходить.
И если Microsoft может «вбить в студию» всё, что дуже угодно — от «функционального программирования» до «ALM». Можно шпиговать разнотравьем, получая пирожок, пахнущий всем сразу. Можно сделать две платформы WPF и Silverlight, а потом прибить их обе. Вообще, Microsoft все спокойно относилась к «плохим запускам». Как в комической индустрии — всегда на долю «хороших» пусков обязательно будет доля «плохих». Вспомните Millennium, Vista. Здесь я не привожу «критику» Microsoft — великой корпорации, которая стала двигателем цивилизации на рубеже XX-XXI вв.
Но вся эта «бесплатная» монета всегда имеет и вторую сторону. Как только доминанта Microsoft была сломлена — нет, не альтернативной настольной системой, а мобильной платформой… точнее сразу 2-мя… Какой прок от бесплатной Visual Studio, если она не даёт создавать приложения под iOS и Android?
Происходит «перегазгузка» компетенций разработчиков. 10 лет C# и Visual Studio не значат ничего.
Кстати, я теперь начал догонять, почему в начале моей деятельности «старые программисты» всегда норовили мне рассказать «про перфокарты» и «машинные коды». Им было до глубине души обидно, что их навыки «заклеивания дырочек» никому не нужны, а ячейки и регистры уже давно другие, никого не парит «засунуть программу в 20 кибайт» и т.д., а p2 = (p = NULL)? ++p: p--; стало цениться больше, чем 20 опыт фортрана.
Теперь Delphi/C++Builder/RAD Studio стала мульти-платформенным средством, акции знания Delphi (C++Builder/RAD Studio) резко подскочили вверх на фоне .NET-скиллов… (кто не верит, посмотрите, сколько стоит iOS-девелопер vs .NET девелопер).
И уже с грустью в голосе Microsoft объявляет партнёрство с Xamarin (сами не могут поддерживать Android и iOS, хотя чисто технически для Microsoft сделать «ms android native studio» проблем не представляет). Всё это к тому, что «прося бесплатный турбо эксплорер» нужно представлять себе причины существования оного в прошлом, доступности Visual Studio Express сегодня, а также проблему «соскакивания» с тулзы или «перезагрузки» компетенации в будущем.
Если есть желание дальше обсудить — welcome. Только давайте не «стоя лбом к стенке», а сделав два шага назад, чтобы видеть всю картину целиком. Кстати, рад буду рассказать и дальше, особенно в контексте «Samsung Android Studio», выхода Tizen, фрагментации рынка мобильных платформ, доли рынка Microsoft в мобильных системах (несмотря на бесплатность Visual Studio Express… извините, не удержался).
Дело в том, что я работал «чистым технарём». Вопросы маркетинга, продвижения, «первой дозы бесплатно» меня мало интересовали, а также доступа к данным не было. Сейчас же у меня больше времени на «осмысление картины в целом». Конечно, хочется ответить на вопрос «бесплатности» лицензий на RAD Studio как «дяди не понимают что-то». К сожалению, это не так, а «дяди готовы объяснить, как мир устроен».
Считайте, что стоимость лицензии на RAD Studio — это цена свободы. Вы не обязаны писать для Windows. Или для Mac OS. Или iOS. Или Android. Свобода того стоит, даже если просто пересчитать стоимость ведения 4 отдельных проектов под 4 разных платформы.
Тут вот вопрос — 18delphi.blogspot.com/2013/08/blog-post_19.html
>>Вы утверждаете обратное?
Где? Найдите хоть одно место, где «я» что-то утверждал. Любите Discover «discovery how it's made»? Ну вот я сделал то же самое. «Мысленно» пришёл в Гарант и походил с камерой, «поснимал» (на мозг) то, как Максим и Александр используют UML в процессе производства ПО. Позадавал вопросы — «зачем»? Вообще ничего не утверждал. Вполне убедился, что UML без кодогенерации не так эффективен, как с кодогенерацией. Не очень понял, почему Вы на это обиделись?
>>Но практической полезности от факта, что кто-то где-то внедрил такой инструмент и процесс — ноль целых, ноль десятых.
Это — очень интересная мысль. Кстати, попробуйте на досуге написать диссертацию. Если (по профилю) Вам 40 лет — то самое время. Вашим профессиональным склонностям вполне подойдёт инженерная специализация. 40 лет — расцвет творческих способностей, когда человек еще не совсем перешёл на руководящие позиции (отстал от жизни), но уже имеет огромный опыт и компетенцию.
Кстати, могу поработать Вашим консультантом. Часто «мной пользовались», чтобы сформулировать тему: предмет, объект, рамки исследования. Цель и задачи. Так вот, без «внедрения» Вам не получить доказательство полезности. А без доказательства полезности, исследования бесполезны. Если бесполезны — то не востребованы. Поэтому факт внедрения UML (определенным способом) является ценнейшим наблюдением. Именно это — обогащение базы знаний человечества, к чему любой преосвященный человек и должен стремиться.
>>Я не спорю, что иметь синхронизированные модель и код может быть полезно, если это не несёт существенных накладных расходов.
А какая польза иметь «рассинхронизированную» модель и код?
>>Вы, извините, за прямоту, уже второй раз тут пукнули в лужу показываете себя не с лучшей стороны.
Весьма занимательный ассоциативный ряд. Не скажу, что очень оригинальный случай, но вполне показательный.
>>Во-первых, какая анонимность на хабре? Загляните в профиль.
Открываем профиль. 11681-й в рейтинге хабралюдей. Ну, хорошо, что не 11682-ой. Уже что-то.
Где а) компания б) проекты в) скрин-шоты работ? Пока только 11681.
Да, что-то я стал сдавать. Бился с №11681 на Хабре…
>>Во-вторых, я не мог даже предположить, что вас настолько заденет то, что вы для меня являетесь меньшим авторитетом, чем признанные эксперты, авторы методологий и многих, многократно переизданных и переведённых книг.
Меня задел только Ваш переход на личности. Вы, конечно, можете извиниться.
Я приму Ваши извинения.
>>В личном общении вы так же обращаетесь к собеседнику, или только когда морда в безопасности в интернете?
Не переоцените Ваши возможности. Говорю это Вам это совершенно серьезно.
>>Заметьте, вы наехали почти на всех комментаторов к статье.
Нужно за слова свои отвечать. Никогда не поздно. Даже в 40 лет.
>>я дискуссию покину.
Разумно.
>>Ну, 3 — это ваше частное мнение.
Ну — хотя бы это «групповое» мнение с привлечением экспертов из «Гаранта». Чтобы это не смотрелось, что я прикрываюсь чужим (заметьте — не книжным, а авторитетом реального большого лидирующего IT-проекта), позволю себе объясниться.
UML без кодогенерации означает, что есть код (если он есть, а это не просто «рисовалово»), а есть диаграммы. Давайте обощим — не диаграммы, а «документация». Чертёж. Если у Вас нет строгой синхронизации (о чём, кстати, написано выше), то рано или поздно будет расхождение. Для программиста код всегда будет важнее документации к нему (даже отбрасывая идею о «самодокументируемости» кода), поэтому, когда настанет черёд выбирать, UML за ненужностью будет отброшен.
Или же Вам придётся постоянно под код подгонять UML, что порочно. Здесь же и появляется идея о запрете на «реверс».
>> Про 1 и 2, вы бы поинтересовались сначала, а то некрасиво.
Я знакомился с UML по первоисточникам. А также по документации к программным средствам моделирования на UML. Зачем мне учебник из серии «для чайников»?
Опять же — Ваш любимый Фаулер. Редкостный халтурщик, если судить по его тонюсенькой книге про UML.
>>Ларман и вот эти люди ниже для меня более авторитетны.
Как авторы книжек для детишек? UML в комиксах?
>>Хотя бы потому, что их труды и достижения я знаю, а ваши пока не попадались.
Переходим к главному. Сейчас будет немного больно.
1. Вы позволили себе перейти на личность, что, само по себе возмутительно. Пользуетесь анонимной безответственностью. Трусливо, но понятно.
2. Когда Вы задаёте такой вопрос, будьте готовы представить Ваши достижения. Кроме троллинга и умением пользоваться google seach по строке «UML books».
3. Ну и главное!
>>а ваши пока не попадались.
Вы просто не там искали.
Посмотрите диссертации за последние 5 лет на тему «применение искусственного интеллекта для построения предметно-ориентированной САПР».
А какую диссертацию написали Вы?
>>Даже обсуждать не хочется.
Какая незадача! Так быстро признать поражение…
>>И заметьте, я не критикую ваш подход.
Потому что не можете. Чего-там не хватает. Опыта? Знаний? Одного темперамента мало!
>>у меня мало о нём информации.
Так спрашивайте! Александр и Максим не оставили ни одного вопроса неотвеченным!
>>Так что не надо на меня нападать.
А это Вы уже с зеркалом разговариваете. Кому Вы нужны, чтобы на Вас нападать?
Может, что-нибудь из своих трудов дадите почитать. Лерман Мартинович Фаулер, Вы наш, непризнанный.
Пока кроме достаточно бедненького списка литературы ничего не представили. Про UML, конечно.
Ну а так — я вполне подозреваю, что Вы — вполне успешный профессионал. Разве что манер маловато. Но это, как обычно
>>ну значит это мои проблемы :)
Ну а теперь, когда Вы всё это прочитали и слегка покраснели от негодования, прочитайте уж и это (до кучи).
Я искренне извиняюсь за причиненную Вам обиду. Совершенно искренне. Не сомневаюсь, что у Вас действительно развитый интеллект и большой талант к программированию. Возможно, нам было бы приятно в дальнейшем общаться, если эта наша размолвка не повлияет на дальнейшее Ваше миропонимание.
Честно скажу, стыдно, когда взрослые люди как-то ругаются из-за пустяков.
2. Про «классиков» в интервью есть отдельная тема. Если Ларман не является действующим разработчиком, то он — классик.
3. «Без кодогенерации» — первая и главная ошибка, если её сделал Ларман, а не Ваша интерпретация.
4.
>>Извлечённые знания в инженерии затем структурируют.
И какая же структуризация «знаний» в терминологии ИИ используется в книге Лармана?
В заголовке статьи фигурирует слово «зачем», а не «что такое» или «как надо». Это и есть основная цель статьи — закрыть пробел в (общечеловеческих) знаниях, именно «зачем» нужен UML.
STL это — «гигиена мозга» ( по определению Леонова), а UML — это «гигиена мозга» в квадрате…
Поймите меня правильно…
И да! Я ЗНАЮ про STL. И УВАЖАЮ Степанова…
И опять же «пну» Embarcadero из под аккаунта Леонова… Я ВООБЩЕ не понимаю КАК Delphi до сих пор живёт БЕЗ STL…
А что до «пну»или не «пну»…
Ребята… Я МНОГО ходил в горы… и САМ вешал верёвки…
И САМ РУКОВОДИЛ командами… Это — МНОГОГО стоит…
Программирование это всё — «чушь» (передёргиваю)
Там совсем ДРУГИЕ отношения…
Кто не верит — пойдёмте со мной в горы… Как минимум на 2Б…
Но и это — НИЧТО не гарантирует…
И ещё. Коллеги!!!
У меня — «чесалось». Но я НЕ МОГУ не УПОМЯНУТЬ — Кирилла Пугина — как одного из разработчиков генератора… Это было бы — нечестно… Он сейчас не с нами, и работает в MicroSoft. Но мы БЛАГОДАРНЫ ему за реализацию САМЫХ «хардкорных» вещей. Спасибо — что он был с нами.
Просто если вы думаете, что мы «слабали эту статью на коленке».
То поверьте — вы СИЛЬНО ошибаетесь… Мы ДОЛГО работали над ней… И многое из неё выкинули… По разным соображениям… И СОГЛАСОВЫВАЛИ это с работодателем… Что — ПОВЕРЬТЕ — для программистов — НЕПРОСТО…
Так что это «не на коленке» и «не джинса»…
Неинтересно — не читайте… Что делать…
Интересно — пишите… Не интересно — жаль… Значит мы недоработали…
Более того… Не знаю — стоит ли это писать… Но напишу…
Друзья мои! Согласовать публикацию статьи в большой конторе когда ты работаешь наёмным работником — это непросто…
В ЛЮБОЙ точке земного шара.