Толчком к написанию данной заметки стали два небольших события. Во-первых, недавнее интервью Мартина Одерски в серии “A-Z programming languages”. Во-вторых, наблюдение за объемом трафика, который генерирует наш внутрикорпоративный Confluence.
Итак, Мартин Одерски неоднократно объяснял, что ориентирование Scala на платформу JVM является стратегическим шагом (я в курсе того, что Scala как-то дышит и на .Net-е, но в контексте данного разговора хрен редьки не слаще). Во-первых, Scala получает стабильную и взрослую среду исполнения (с HotSpot-ом, сборщиками мусора, адаптацией к куче разных аппаратных платформ и ОС). Во-вторых, Scala получает огромных размеров готовую библиотеку и возможность взаимодействия с большим количеством существующего Java кода. В-третьих, Scala за счет двух первых пунктов претендует на переманивание изрядного количества Java-программистов в свои ряды.
Однако, все это означает, что интересный язык программирования затачивается исключительно под управляемую среду. Со всеми вытекающими отсюда тормозами. И я таки буду настаивать, что управляемый код – это тормоза. Та же ItelliJ IDEA или Eclipse, которые часто приводят в качестве быстрых Java-программ, на мой взгляд – изрядные тормоза. Может быть потому, что я видел, как начинали летать Word 6.0 и Visual Studio 4.2 при их запуске не на 486DX2-80 с 8Mb, а на Pentium 200MMX с 32Mb. Вот это была скорость. А то, что для IDEA нужен 2GHz процессор и 2Gb памяти чтобы нормально работать – это таки диагноз.
Теперь о Confluence. Работая в 1Gb офисной сетке не очень-то замечаешь, сколько весят ее странички. Понятно, что весят достаточно, чтобы открываться не мгновенно. Вообще-то стиль Web-приложений убивает напрочь. Со времен MS-DOS-а выработалась привычка к тому, что новые окна открываются или старые обновляются практически мгновенно. А тут приходит эра Web-приложений и после нажатия на кнопку “OK” в каком-то диалоге требуется около секунды для того, чтобы перерисовалось старое окно. В общем, павбывавбы, да не о том хочется сказать…
Так вот сегодня, по ADSL каналу в 128kbps, грузил простенькую страничку из Confluence. Страничка завесила почти 1Mb (950+ KB, если не ошибаюсь). Афигеть! На днях я закончил два компонента, DLL-ки с которыми весят по 450KB каждая. И делают они гораздо больше полезного для народного хозяйства, чем эта мегабайтная страничка.
А тут еще ходят слухи о пришествии Web-приложений на desktop. Типа растет новый класс Web-приложений, которые способны работать в браузере и в оффлайне, в том числе и сохраняя свое состояние на локальном жестком диске. Слухами я называю это потому, что очень далек от области Web-разработки, поэтому не очень в курсе того, насколько это жизнеспособно сейчас и какие у этого перспективы. Однако, в то, что на каком-нибудь JavaScript-е или Flash-е скоро начнут делать автономные desktop-ные приложения, я уверен.
После столь долгой преамбулы пора переходить к амбуле. Не то, чтобы я был прирожденным фанатом быстродействия, но программистское бытиё заставляет таковым становиться. Во-первых, на работе нагрузки на разработанные мной системы постоянно растут. Поэтому проблемам быстродействия и масштабирования приходится уделять все больше внимания (причем больше быстродействия, чем масштабирования).
Во-вторых, я уже несколько месяцев являюсь владельцем нетбука. И это заставляет смотреть совсем по другому на нынешнее софтостроение. Нетбуки – это совсем другой мир. У них в ближайшее время вряд ли будет хорошее быстродействие (все-таки быстродействие – это цена, а сила нетбуков в их низкой цене). Мой маломощный нетбук с VIA-процессором начинает громогласно гудеть при более-менее серьезной нагрузке. А что создает на нем нагрузку? В большинстве случаев – браузер, когда открывает страничку с Flash-евой рекламой. Страшно подумать, что будет, когда на нетбуки придут desktop-ные приложения на JavaScript-е и Flash-е.
Второй фактор, который серьезно отдаляет мир нетбуков от всего остального мира – это размер экрана. Разрешения 1024x600 для 9” экранов или даже 1280x800 для 11” можно считать практически пределом. Не думаю, что здесь что-то серьезно улучшиться. Ведь даже 13” экран сразу переводит девайс в совсем другую категорию за счет существенно больших габаритов. А ведь маленький вес и размер в купе с низкой ценой и есть основные причины покупки нетбуков.
Итак, экраны у нетбуков маленькие как по размеру, так и по разрешению. А это ведет к тому, что разработанные для больших братьев приложения на нетбуках становятся малопригодными к использованию. Большие рамки у окон, большие картинки в тулбарах, широкие скроллбары, красочные диалоги с картинками и обилием пустого места, крупные шрифты – все это прекрасно выглядит на FullHD дисплеях, но является откровенным издевательством на нетбуках.
Таким образом, сочетание низкой производительности и малых экранов, на мой взгляд, должно привести к появлению программ, адаптированных специально для нетбуков. Ведь продажи нетбуков уже исчисляются десятками миллионов в год и грозятся увеличиваться в разы в ближайшее время. Это серьезный рынок и кто-то может его освоить.
Но, если под нетбуки нужно специально затачивать приложения, то на чем их писать? На JVM-овской Scala/Java или .Net-овских C#/VB/F#? Или на нативных C/C++? Широко распространенных, но опасных. К тому же имеющих репутацию медленных в разработке. Или же где-то там (якобы) живущим, но тоже нативным OCaml-у с Haskell-ем? Или известным только фанатам диалектам Common Lisp-а? А может быть на Ada или Oberon?
На мой взгляд, приложения для нетбуков (да и не только для нетбуков) должны разрабатываться на нативных языках. Но безопасных. И я не очень понимаю, почему сейчас сложилось мнение, что управляемые среды – это безопасно, а неуправляемые, нативные – это опасно? Может быть из-за флагманов этих сред – Java/C# vs С/C++?
Но я, к примеру, начинал серьезно осваивать программирование на очень нативном и очень безопасном Turbo Pascal-е. Выходы за пределы массива или переполнение буферов там вылавливалось на раз. При очень маленьких размерах исполнимого кода и вполне приличной скорости его работы. Так что очень зря между “управляемостью” и “безопасностью” автоматически ставится знак равенства.
Таки пора уже озвучивать давно обещанную амбулу. Нетбуки могли бы дать толчок к разработке новых, современных приложений на нативных языках. Но новые, многообещающие языки (C# и Scala) как раз ориентированы на управляемые среды. А где новые, многообещающие, мощные и безопасные промышленные нативные языки? Или таковым считается только Haskell? Сможет ли распространение нетбуков подтолкнуть кого-нибудь к созданию чего-то вроде Scala, но для нативного кода?
Честно говоря, я сам в это не верю. Хотелось бы, но не верю. Имхо, сейчас вообще у любого нового языка программирования будет очень мало шансов стать широко распространенным инструментом (в очередной раз поминаю незлым тихим словом долгострой под названием D). И рынки нетбуков или многоядерных машин будет проще окучивать с помощью адаптированных старых лидеров (опять же Java, C#, C++0x), чем с помощью чего-то нового. Хотя…
PS. Под старыми-добрыми временами я подразумевал начало 90-х, когда при написании, скажем, текстового редактора под MS-DOS, Windows или OS/2, не было большого выброра – C, C++, Pascal, Modula-2 да и все, пожалуй. Хорошие времена были. Трава зеленее, вода мокрее… :)
На нетбуке с Intel Atom производительность вполне нормальная, я даже умудрялся работать в VirtualBox c рабочей операционкой с Visual Studio внутри :)
ОтветитьУдалитьЭкран да конечно мелковат.
Насчет десктопных javascript, десктопные приложения давно пишут на питоне и tcl по моему у них с производительностью проблем нет. Конечно часто используется небольшое c/c++ ядро но не обязательно, даже у чистых приложений все нормально.
Haskell при всей его стройности и красоте по моему мало пригоден для обычной работы и для разработки не спицифичных (компиляторы) крупных приложений. Как пример могу привести Darcs который не может соревноватся даже с написанными на питоне Mercurial, Bazaar ни по производительности ни самое смешное даже по надежности.
Вот OCaml другое дело. Это вполне нормальный императивный язык который позволяет писать в функциональном стиле :)
У него только одна проблема мало библиотек, но в последнее время есть подвижки, плюс надежда что F# в майнстриме даст и OCaml'у импульс к развитию.
Если основная работа десктопного приложения -- диалоги с пользователем вести, то производительности любого скриптового языка здесь за глаза хватит. А если что-нибудь вычислительное (картинки масштабировать или орфографию проверять), то сомневаюсь.
ОтветитьУдалитьПо поводу F# и OCaml сомневаюсь. OCaml сам в последнее время на меня производит впечатление заброшенного языка. Да и странный от какой-то. Мне не понравился :) Программы на нем, например, сложно читать.
Ну я вообще-то писал на питоне как раз узкоcпециализированные графические редакторы, конечно все тяжеловычислительное делали модули написанны на си, но это по большей части были стороние готовые модули, самописного кода на C++ по объему было меньше 20%.
ОтветитьУдалитьЯ согласен что OCaml коряв и неуклюж, реальный верблюд :) . Но код писать и читать на нем легко. Читабельность вполне на уровне питона, но нужна привычка конечно. Я тут собираюсь относительно серъезную вещь на нем начать на несколько человеко-месяцев.
Мне довелось делать графический векторный редактор для SCADA-системы. По воспоминаниям, самая большая часть работы там -- это слежение за действиями пользователя и диалоги по назначению свойств линии, многоугольников, групп фигур и пр.
ОтветитьУдалитьPS. А несколько человеко-месяцев -- это даже не "относительно серьезная вещь" ;)
Ты один будешь писать или в команде?
У меня были растровые редакторы, там все тяжелое легко выносится в C++.
ОтветитьУдалитьНесколько человеко-месяцев это очень серъезно если до этого писал максимум на человеко-неделю :)
Ну и в шароваре в которую хочу вернутся для старта тратить больше обычно бессмысленно.
Писать один буду.
Да, хорошо, когда пишешь один. И язык можно под себя выбрать. И процесс проще идет. И в надежности результатов больше уверенности...
ОтветитьУдалитьимхо. нетбуки имеют очень низкий порог цены софта. грубо говоря за 25$ никто "затачиваться" не будет. Тут будет раздолье тем для кого это не основной доход.
ОтветитьУдалитьРазработка нового языка - это за гранью фантастики. Сейчас на это могут решиться 2-4 корп в мире и то если будет существенный мотив. Например решат как таки быть с data parallelism и тп.
зы (суровое имхо) очень многое что в 90е было написано на си/++ ускорится от переноса на жабу. То есть разница между си++ и жабой меньше чем разница между девелоперами разной "весовой категории".
2Rubanets Myroslav: по поводу новых языков у меня такое же мнение. Хотя маленькая надежда теплится, что C++ это еще не последний шаг в эволюции нативных языков. Делают же разные Cyclone и Lisac-и.
ОтветитьУдалитьА по поводу C++/Java -- имхо, не бысрее бы стали, а стабильнее. Хотя, опять же, на том же нативном Eiffel-е писать можно столь же быстро, как на C++, и столь же надежно, как на Java. Может быть, даже надежнее.
Rubanets Myroslav угу java по микротестам очень близка к C++ но реальные десктоп приложения почему-то тормознее аналогов не только на C++ но и даже на NET.
ОтветитьУдалить2Rustam
ОтветитьУдалитьмикротестами я не интересуюсь. Средний с++ 90х очень не далеко от джавы - клинически наблюдаемый факт. Есть некоторые программы которые прекрасно сбалансированы в сторону минимизации объема ресурсов, но их очень мало даже среди нативных.
Чё-то ты как-то не в контексте немножко, по-моему :)
ОтветитьУдалитьДесктопные приложения на флеше и JS давно уже пишут.
Кроме того, под тот же iPhone изначально единственным способом создать собственное приложение были вёб-приложения. А гугль, с помпой анонсируя ChromeOS (по сути, браузер без ОС), предназначает её в одну из первых голов именно для нетбуков.
А нативный код используется там именно в том контексте, в котором надо — для написания небольших модулей, критичных к железу/производительности.
ЗЫ: про технологии типа AIR я когда-то писал статью. А про то, зачем это нужно и что даёт — «лёгкость» управляемых языков и игрушечных сред — когда-то писал другую.
2zverok-kha: да я давно уже не в курсе... Сижу тут с напильником который месяц, починяю примус... :)
ОтветитьУдалитьПо поводу iPhone -- не знаю, что там было вначале, но уже давно в соседнем кубикле сидит коллега, который фигачит приложения для iPhone на Objective-C.
Имхо, возможность написания более-менее серьезного софта как на Java/C#, так и динамических языках стала возможной благодоря росту производительности. Что имеет как хорошие, так и отрицательные стороны. Итог чего, на мой взгляд, явный крен в область managed языков и сред. Что не есть хорошо. А вот нетбуки имеют совсем другую производительность. Может хоть она даст понять, что native -- это не плохо, а даже наоборот.
Может это просто VIA процессор тормозной?
ОтветитьУдалитьПросто, как уже писал, некторое время у меня был нетбук с процессором Intel Atom. Пускал на нем кстати и eclipse с OCaml плугином, вполне нормально (кроме размера экрана) работать можно. Или может из-за памяти там 2 метра стояло.
zverok-kha ChromeOS вроде просто Linux с Chrome.
ОтветитьУдалитьЗаговор это, вы что -)
ОтветитьУдалитьэто тоже самое, как заговор производителей железа и разработчиков игр - игра требовательна к видеокарте, геймер купит новейшую.
Остается неохваченым рынок офисных компов, их тоже надо обновлять, как то подстегнуть народ. Вот и начали клевать всевозможные дотнеты, которые облегчают жизнь программерам, но напрягают жизнь другим .
Но это так шутка, с долей шутки.
Вообще давно заметил на своем ноуте 4 летней давности (кстати гораздо быстрее того же атома, оперативы 2 гига), что наиболее распростаненные сервисы на ява скрипте (например тот же gmail), или страничка с флэшем отъедеает не позволительно много процессорного времени. VmWare с виндой напрягает может чуть сильнее. но это полноценная операционка, а не страничка в вебе
2Rustam: VIA действительно тормозной. А что до того, что на Atom-е можно разработку вести, так я в свое время программы на C++ писал под Linux-ом на ноутбуке P133 и 32Mb памяти (+ 1.3Gb HDD). С использованием STL и исключений. А уж что до этого было ;)
ОтветитьУдалить2Ctapmex: мне кажется, что одной из причин происходящего является то, что сейчас программисты делают так, как удобно им (нам). А хуле заморачиваться эффективным и компактным приложением, если можно взять пару готовых библиотек, склеить их на Ruby и заставить пользователя поставить себе надцать мегабайт зависимостей. Ведь все равно моща растет, диски пухнут и т.д. и т.п. Зато быстро, с колокольчиками и бубенцами.
ОтветитьУдалитьА мнения пользователей мало кого интересует. В результате, при поиске простого, но функционального аудио или видеоплейера на 2-3 нормальных приложения оказывается пару десятков слепленных абы как монстров. Некоторые из которых к своему собственному дистрибутиву требуют еще и JRE или .NET.
Может это и нормальное развитие событий. Но хотелось бы в консерватории что-нибудь подправить :) Чтобы заговоров не было :))
Преамбула: Давно наблюдаю, как "нативные" программисты живут в каком-то кошмаре "конца света", "последних времен" (Хорошие времена были... прошли... Кали-Юга...) и потому светлом и напряженном ожидании пришествия спасения в виде "C++ + Qt". (у "функциональщиков" схожее ощущение - императищина гниет, ...). С психологической точки зрения вызвано ощущением - "маргинальности", и "аутсайдерства".
ОтветитьУдалитьТеперь о делах наших программерских :)
А почему же так случилось в айти-отрасли?
Вот я, прикладной программист всю дорогу, с 93его. Вначале инструментом был plain Си. А далее - только "управляемые" - FoxPro, MUMPS, 1C, Java и C#. Потому что - Факт 41: Стоимость сопровождения обычно составляет от 40 до 80% (в среднем 60%) стоимости ПО. Следовательно, эта фаза его жизненного цикла, возможно, самая важная. (Роберт Гласс)
И чем меньше у приложения пользователей, тем дороже им приложение обойдется конечному пользователю. Если программист готов бесплатно "заморачиваться эффективным и компактным приложением" - пусть изменит мир :) Рынок же, в виде пользователя, пока решил выбрать то что дешевле и разрабатывается быстрее, чем высокоэффективное(по аппаратным ресурсам) но дорогое и долгоразрабатываемое. А железячники - этому весьма и весьма помогают.
О нетбуках. Согласен, что указанные изъяны - тяжеловесность и неприспособленость GUI решений для десктопов - требуют переработки. Вот только... чего, в какой части приложений? Ведь задачи такой не ставилось, пока, а если, скажем для Java появится кроме Swing и SWT - какаянить - compactXXX, угонятся ли "нативщики" по скорости и стоимости разработки? Ведь сами JVM и CLR не так уж сильно медленее и прожорливей(на C# пишу под WinMo), чтобы имело смысл связываться с неуправляемым кодом. А тормозной эффект создают сонные реакции интерфейса. Второй момент массовость программистов. Ведь не секрет, что нативные ЯП требуют более серьезных знаний и навыков программиста (иначе программист только и будет заниматься борьбой с глюками, а не задачей, что и видно по выпускникам "знающим С++").
Паскаль, Оберон, да, могли бы несколько помочь... но на сейчас - кому нужны чистые ЯП, без массы библиотек. А кто ж ими займется для них?
> А мнения пользователей мало кого интересует
Меня, прикладного программиста работающего напрямую с пользователями - еще как интересует :) Как и толщина их кошелька и размер терпения чтобы ждать.
> Хотя, опять же, на том же нативном Eiffel-е писать можно столь же быстро, как на C++. и столь же надежно, как на Java. Может быть, даже надежнее.
Жизнь - лучший арбитр :)
Через пару-тройку лет увидим. Но думается, скорей нетбуки станут мощнее, чем отрасль пойдет в старые времена - в удорожание разработки ПО. Не за счет умощнения процессора, а за счет реализации в "камне" функций, что на десктопах выполнял универскальный процессор.
2Skynin: на все ответить в комментарии не могу, т.к. очень много хочется сказать. Лучше я отдельный пост напишу на эту тему. Прокомментирую лишь один момент.
ОтветитьУдалить> угонятся ли "нативщики" по скорости и стоимости разработки?
Я смотрю на это так: современные managed платформы уделывают, в первую очередь, C++ за счет двух главных факторов -- безопасности и сборке мусора (из чего со временем сложилось и преимущество в количестве библиотек). Однако, практика в лице Oberon и Eiffel показала, что эти же качества можно обеспечить и для натива. Т.о., если сравнить какой-то гипотетический современный безопасный нативный язык со сборкой мусора и ту же Java, то я уверен в том, что на таком языке можно было бы угнаться. И даже перегнать из-за убогости Java как языка программирования. Вот с C# сложнее, пока он слишком быстро развивается и впитывает новые хорошие идеи.
> И даже перегнать из-за убогости Java как языка программирования.
ОтветитьУдалитьТак убогость Java и была взята из Оберона :) Как раз для 1) низкого порога вхождения = привлечения масс кодеров разной степени талантливости и опыта 2) исключения опасных и сложных в понимании конструкций. (сложное в понимании - приводит к дороговизне "сопровождения" кода)
> Однако, практика в лице Oberon и Eiffel показала, что эти же качества можно обеспечить и для натива.
С помощью правильного проектирования, выверенной методологии ведения проектов и опытной команды - и на ассемблере можно тааааакое писать...
То есть большой вопрос - в конкретных проектах было чего больше - влияния свойств ЯП или вышеперечисленного?
> Вот с C# сложнее, пока он слишком быстро развивается и впитывает новые хорошие идеи.
C# с его лямбдами, LINQ и дженериками почти как Scala становится :)
> Лучше я отдельный пост напишу на эту тему.
Да, хорошо, с Вами, как опытным и вменяемым "нативщиком"(извините за ярлычок, просто для краткости) интересно было обсудить - тезисы причин ухода неуправляемых языков с массового применения. Ввиду собственной далекости, а потому ограниченности.
2Skynin:
ОтветитьУдалить> То есть большой вопрос - в конкретных проектах было чего больше -
влияния свойств ЯП или вышеперечисленного?
Методологии, команды и пр. можно особенно не рассматривать. Поскольку если речь идет о мейнстримовых ООП языках, то там без особой разницы -- используется ли C++ или Java. Методы и даже паттерны проектирования одинаково ложатся и туда, и туда.
А вот языковые свойства влияют довольно сильно. Поскольку, если меня устраивает производительность решения, то лучше предпочесть более безопасный язык со сборкой мусора (GC -- это вообще очень и очень важный момент).
Даже если брать чистой воды натив: С++ и D. Поскольку даже D 1.0 более безопасен и лаконичен, чем C++, да еще и со сборкой мусора, то на D то же самое можно получить быстрее, чем на C++. Как раз за счет того, что меньше отвлекаешься на технические детали.
Но еще больше языковых возможностей прирост производительности дают готовые библиотеки. А здесь опять же, чем удобнее в разработке язык (безопасность+GC), тем проще создаются библиотеки. Что и наблюдается на примерах Java и C++.
Так что, имхо, языковые свойства имеют важное значение (как прямое, так и косвенное). Хотя и далеко не решающее. Скажем, кривые руки разработчика свойствами языка не выправить. :(
В целом согласен. И похоже, Вы сами почти ответили на вопросы: Поскольку, если меня устраивает производительность решения, то лучше предпочесть более безопасный язык. Осталось только вернуться к нетбукам, и выяснить - действительно ли невозможно для них разрабатывать ПО на управляемых ЯП c приемлимой для пользователя производительностью. И еще один момент, который меня интересует, но не встречал, а специально не искал - возможности рефлексии кода - реализуемы в неуправляемых ЯП так же просто как в чистых интерпретаторах или управляемых ЯП? Потому что как раз для многих прикладных библиотек и методов прикладного программирования - весьма удобная штука - рефлексия кода. (подчеркнул - прикладных - потому что системные вещи и геймдев обычно имеют более устойчивые во времени требования, заказчик системного ПО обычно не персонализирован, и все равно подождет. Например - выпуск новой версии ERP платформы можно откладывать, а вот прикладное решение на ней, в ввиду изменений законодательства - низя)
ОтветитьУдалитьИли, новый пост напишете, и там уже обменяемся мнениями-размышлениями :)
Skynin рефлексия вполне заменяется метапрограммированием. Основной недостаток C++ метапрограммирование в нем доступно, но его очень тяжело использовать, очень высок порог вхождения и метапрограммы писать приходится на очень корявом и убогом языке шаблонов. D эту ситуацию полностью исправляет во первых намного более удобные шаблоны, во вторых рефлексия времени компилирования. Ну и функциональщина в этом тоже на высоте в тех же окамле и хаскеле и сами языки очень выразительны и мета вполне доступно
ОтветитьУдалить2Skynin:
ОтветитьУдалитьвозможности рефлексии кода - реализуемы в неуправляемых ЯП так же просто как в чистых интерпретаторах или управляемых ЯП?
Насколько я помню, то рефлексия имеет два основных применения -- a) сериализация/десериализация объектов или чтение/модификация атрибутов объектов по метаинформации о его структуре и b) вызов производьного метода объекта с передачей аргументов метода через массив объектов.
Первая задача в нативных языках решается через внешние инструменты. Например, сериализация разных видов (тот же ASN1 или Google Protocol Buffers). Никаких сложностей нет, поскольку сериализации/десериализации подвергаются далеко не все типы.
А вот вызов любого метода на основании метаинформации о нем -- тут да, вроде бы в общем случае это не делается.
Но это по моему опыту. Может я чего-то не знаю.
Меня не интересовал ответ о тьюринг-полноте, потому что большинство широко используемых языков тьюринг полные (... называется тьюринг-полным, если на нём можно реализовать любую вычислимую функцию)
ОтветитьУдалитьЧто не делает равноудобными для конкретных задач хаскел, джаву и Brainfuck.
Рефлексия же часто является палочкой выручалочкой когда нет времени на проектирование или рефакторинг для встраивания новой функциональности. Рефлексия в идеале - это средство добавления удобств динамических ЯП в статические.
Но мы отклонились от темы.
2Skynin
ОтветитьУдалитьс вашего позволения я утащу в цитаты ( уж больно понравилось ):
"Рефлексия же часто является палочкой выручалочкой когда нет времени на проектирование"