понедельник, 24 августа 2009 г.

[comp.flame] Вернут ли нетбуки старые-добрые времена?

Толчком к написанию данной заметки стали два небольших события. Во-первых, недавнее интервью Мартина Одерски в серии “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 да и все, пожалуй. Хорошие времена были. Трава зеленее, вода мокрее… :)

26 комментариев:

Rustam комментирует...

На нетбуке с Intel Atom производительность вполне нормальная, я даже умудрялся работать в VirtualBox c рабочей операционкой с Visual Studio внутри :)
Экран да конечно мелковат.

Насчет десктопных javascript, десктопные приложения давно пишут на питоне и tcl по моему у них с производительностью проблем нет. Конечно часто используется небольшое c/c++ ядро но не обязательно, даже у чистых приложений все нормально.

Haskell при всей его стройности и красоте по моему мало пригоден для обычной работы и для разработки не спицифичных (компиляторы) крупных приложений. Как пример могу привести Darcs который не может соревноватся даже с написанными на питоне Mercurial, Bazaar ни по производительности ни самое смешное даже по надежности.
Вот OCaml другое дело. Это вполне нормальный императивный язык который позволяет писать в функциональном стиле :)
У него только одна проблема мало библиотек, но в последнее время есть подвижки, плюс надежда что F# в майнстриме даст и OCaml'у импульс к развитию.

Евгений Охотников комментирует...

Если основная работа десктопного приложения -- диалоги с пользователем вести, то производительности любого скриптового языка здесь за глаза хватит. А если что-нибудь вычислительное (картинки масштабировать или орфографию проверять), то сомневаюсь.

По поводу F# и OCaml сомневаюсь. OCaml сам в последнее время на меня производит впечатление заброшенного языка. Да и странный от какой-то. Мне не понравился :) Программы на нем, например, сложно читать.

Rustam комментирует...

Ну я вообще-то писал на питоне как раз узкоcпециализированные графические редакторы, конечно все тяжеловычислительное делали модули написанны на си, но это по большей части были стороние готовые модули, самописного кода на C++ по объему было меньше 20%.

Я согласен что OCaml коряв и неуклюж, реальный верблюд :) . Но код писать и читать на нем легко. Читабельность вполне на уровне питона, но нужна привычка конечно. Я тут собираюсь относительно серъезную вещь на нем начать на несколько человеко-месяцев.

Евгений Охотников комментирует...

Мне довелось делать графический векторный редактор для SCADA-системы. По воспоминаниям, самая большая часть работы там -- это слежение за действиями пользователя и диалоги по назначению свойств линии, многоугольников, групп фигур и пр.

PS. А несколько человеко-месяцев -- это даже не "относительно серьезная вещь" ;)
Ты один будешь писать или в команде?

Rustam комментирует...

У меня были растровые редакторы, там все тяжелое легко выносится в C++.

Несколько человеко-месяцев это очень серъезно если до этого писал максимум на человеко-неделю :)

Ну и в шароваре в которую хочу вернутся для старта тратить больше обычно бессмысленно.

Писать один буду.

Евгений Охотников комментирует...

Да, хорошо, когда пишешь один. И язык можно под себя выбрать. И процесс проще идет. И в надежности результатов больше уверенности...

Rubanets Myroslav комментирует...

имхо. нетбуки имеют очень низкий порог цены софта. грубо говоря за 25$ никто "затачиваться" не будет. Тут будет раздолье тем для кого это не основной доход.
Разработка нового языка - это за гранью фантастики. Сейчас на это могут решиться 2-4 корп в мире и то если будет существенный мотив. Например решат как таки быть с data parallelism и тп.

зы (суровое имхо) очень многое что в 90е было написано на си/++ ускорится от переноса на жабу. То есть разница между си++ и жабой меньше чем разница между девелоперами разной "весовой категории".

Евгений Охотников комментирует...

2Rubanets Myroslav: по поводу новых языков у меня такое же мнение. Хотя маленькая надежда теплится, что C++ это еще не последний шаг в эволюции нативных языков. Делают же разные Cyclone и Lisac-и.

А по поводу C++/Java -- имхо, не бысрее бы стали, а стабильнее. Хотя, опять же, на том же нативном Eiffel-е писать можно столь же быстро, как на C++, и столь же надежно, как на Java. Может быть, даже надежнее.

Rustam комментирует...

Rubanets Myroslav угу java по микротестам очень близка к C++ но реальные десктоп приложения почему-то тормознее аналогов не только на C++ но и даже на NET.

Rubanets Myroslav комментирует...

2Rustam
микротестами я не интересуюсь. Средний с++ 90х очень не далеко от джавы - клинически наблюдаемый факт. Есть некоторые программы которые прекрасно сбалансированы в сторону минимизации объема ресурсов, но их очень мало даже среди нативных.

Анонимный комментирует...

Чё-то ты как-то не в контексте немножко, по-моему :)

Десктопные приложения на флеше и JS давно уже пишут.

Кроме того, под тот же iPhone изначально единственным способом создать собственное приложение были вёб-приложения. А гугль, с помпой анонсируя ChromeOS (по сути, браузер без ОС), предназначает её в одну из первых голов именно для нетбуков.

А нативный код используется там именно в том контексте, в котором надо — для написания небольших модулей, критичных к железу/производительности.

ЗЫ: про технологии типа AIR я когда-то писал статью. А про то, зачем это нужно и что даёт — «лёгкость» управляемых языков и игрушечных сред — когда-то писал другую.

Евгений Охотников комментирует...

2zverok-kha: да я давно уже не в курсе... Сижу тут с напильником который месяц, починяю примус... :)

По поводу iPhone -- не знаю, что там было вначале, но уже давно в соседнем кубикле сидит коллега, который фигачит приложения для iPhone на Objective-C.

Имхо, возможность написания более-менее серьезного софта как на Java/C#, так и динамических языках стала возможной благодоря росту производительности. Что имеет как хорошие, так и отрицательные стороны. Итог чего, на мой взгляд, явный крен в область managed языков и сред. Что не есть хорошо. А вот нетбуки имеют совсем другую производительность. Может хоть она даст понять, что native -- это не плохо, а даже наоборот.

Rustam комментирует...

Может это просто VIA процессор тормозной?
Просто, как уже писал, некторое время у меня был нетбук с процессором Intel Atom. Пускал на нем кстати и eclipse с OCaml плугином, вполне нормально (кроме размера экрана) работать можно. Или может из-за памяти там 2 метра стояло.

Rustam комментирует...

zverok-kha ChromeOS вроде просто Linux с Chrome.

Ctapmex комментирует...

Заговор это, вы что -)
это тоже самое, как заговор производителей железа и разработчиков игр - игра требовательна к видеокарте, геймер купит новейшую.
Остается неохваченым рынок офисных компов, их тоже надо обновлять, как то подстегнуть народ. Вот и начали клевать всевозможные дотнеты, которые облегчают жизнь программерам, но напрягают жизнь другим .
Но это так шутка, с долей шутки.

Вообще давно заметил на своем ноуте 4 летней давности (кстати гораздо быстрее того же атома, оперативы 2 гига), что наиболее распростаненные сервисы на ява скрипте (например тот же gmail), или страничка с флэшем отъедеает не позволительно много процессорного времени. VmWare с виндой напрягает может чуть сильнее. но это полноценная операционка, а не страничка в вебе

Евгений Охотников комментирует...

2Rustam: VIA действительно тормозной. А что до того, что на Atom-е можно разработку вести, так я в свое время программы на C++ писал под Linux-ом на ноутбуке P133 и 32Mb памяти (+ 1.3Gb HDD). С использованием STL и исключений. А уж что до этого было ;)

Евгений Охотников комментирует...

2Ctapmex: мне кажется, что одной из причин происходящего является то, что сейчас программисты делают так, как удобно им (нам). А хуле заморачиваться эффективным и компактным приложением, если можно взять пару готовых библиотек, склеить их на Ruby и заставить пользователя поставить себе надцать мегабайт зависимостей. Ведь все равно моща растет, диски пухнут и т.д. и т.п. Зато быстро, с колокольчиками и бубенцами.

А мнения пользователей мало кого интересует. В результате, при поиске простого, но функционального аудио или видеоплейера на 2-3 нормальных приложения оказывается пару десятков слепленных абы как монстров. Некоторые из которых к своему собственному дистрибутиву требуют еще и JRE или .NET.

Может это и нормальное развитие событий. Но хотелось бы в консерватории что-нибудь подправить :) Чтобы заговоров не было :))

Skynin комментирует...

Преамбула: Давно наблюдаю, как "нативные" программисты живут в каком-то кошмаре "конца света", "последних времен" (Хорошие времена были... прошли... Кали-Юга...) и потому светлом и напряженном ожидании пришествия спасения в виде "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# сложнее, пока он слишком быстро развивается и впитывает новые хорошие идеи.

Skynin комментирует...

> И даже перегнать из-за убогости Java как языка программирования.
Так убогость Java и была взята из Оберона :) Как раз для 1) низкого порога вхождения = привлечения масс кодеров разной степени талантливости и опыта 2) исключения опасных и сложных в понимании конструкций. (сложное в понимании - приводит к дороговизне "сопровождения" кода)

> Однако, практика в лице Oberon и Eiffel показала, что эти же качества можно обеспечить и для натива.
С помощью правильного проектирования, выверенной методологии ведения проектов и опытной команды - и на ассемблере можно тааааакое писать...

То есть большой вопрос - в конкретных проектах было чего больше - влияния свойств ЯП или вышеперечисленного?

> Вот с C# сложнее, пока он слишком быстро развивается и впитывает новые хорошие идеи.
C# с его лямбдами, LINQ и дженериками почти как Scala становится :)

> Лучше я отдельный пост напишу на эту тему.
Да, хорошо, с Вами, как опытным и вменяемым "нативщиком"(извините за ярлычок, просто для краткости) интересно было обсудить - тезисы причин ухода неуправляемых языков с массового применения. Ввиду собственной далекости, а потому ограниченности.

Евгений Охотников комментирует...

2Skynin:

> То есть большой вопрос - в конкретных проектах было чего больше -
влияния свойств ЯП или вышеперечисленного?

Методологии, команды и пр. можно особенно не рассматривать. Поскольку если речь идет о мейнстримовых ООП языках, то там без особой разницы -- используется ли C++ или Java. Методы и даже паттерны проектирования одинаково ложатся и туда, и туда.

А вот языковые свойства влияют довольно сильно. Поскольку, если меня устраивает производительность решения, то лучше предпочесть более безопасный язык со сборкой мусора (GC -- это вообще очень и очень важный момент).

Даже если брать чистой воды натив: С++ и D. Поскольку даже D 1.0 более безопасен и лаконичен, чем C++, да еще и со сборкой мусора, то на D то же самое можно получить быстрее, чем на C++. Как раз за счет того, что меньше отвлекаешься на технические детали.

Но еще больше языковых возможностей прирост производительности дают готовые библиотеки. А здесь опять же, чем удобнее в разработке язык (безопасность+GC), тем проще создаются библиотеки. Что и наблюдается на примерах Java и C++.

Так что, имхо, языковые свойства имеют важное значение (как прямое, так и косвенное). Хотя и далеко не решающее. Скажем, кривые руки разработчика свойствами языка не выправить. :(

Skynin комментирует...

В целом согласен. И похоже, Вы сами почти ответили на вопросы: Поскольку, если меня устраивает производительность решения, то лучше предпочесть более безопасный язык. Осталось только вернуться к нетбукам, и выяснить - действительно ли невозможно для них разрабатывать ПО на управляемых ЯП c приемлимой для пользователя производительностью. И еще один момент, который меня интересует, но не встречал, а специально не искал - возможности рефлексии кода - реализуемы в неуправляемых ЯП так же просто как в чистых интерпретаторах или управляемых ЯП? Потому что как раз для многих прикладных библиотек и методов прикладного программирования - весьма удобная штука - рефлексия кода. (подчеркнул - прикладных - потому что системные вещи и геймдев обычно имеют более устойчивые во времени требования, заказчик системного ПО обычно не персонализирован, и все равно подождет. Например - выпуск новой версии ERP платформы можно откладывать, а вот прикладное решение на ней, в ввиду изменений законодательства - низя)

Или, новый пост напишете, и там уже обменяемся мнениями-размышлениями :)

Rustam комментирует...

Skynin рефлексия вполне заменяется метапрограммированием. Основной недостаток C++ метапрограммирование в нем доступно, но его очень тяжело использовать, очень высок порог вхождения и метапрограммы писать приходится на очень корявом и убогом языке шаблонов. D эту ситуацию полностью исправляет во первых намного более удобные шаблоны, во вторых рефлексия времени компилирования. Ну и функциональщина в этом тоже на высоте в тех же окамле и хаскеле и сами языки очень выразительны и мета вполне доступно

Евгений Охотников комментирует...

2Skynin:

возможности рефлексии кода - реализуемы в неуправляемых ЯП так же просто как в чистых интерпретаторах или управляемых ЯП?

Насколько я помню, то рефлексия имеет два основных применения -- a) сериализация/десериализация объектов или чтение/модификация атрибутов объектов по метаинформации о его структуре и b) вызов производьного метода объекта с передачей аргументов метода через массив объектов.

Первая задача в нативных языках решается через внешние инструменты. Например, сериализация разных видов (тот же ASN1 или Google Protocol Buffers). Никаких сложностей нет, поскольку сериализации/десериализации подвергаются далеко не все типы.

А вот вызов любого метода на основании метаинформации о нем -- тут да, вроде бы в общем случае это не делается.

Но это по моему опыту. Может я чего-то не знаю.

Skynin комментирует...

Меня не интересовал ответ о тьюринг-полноте, потому что большинство широко используемых языков тьюринг полные (... называется тьюринг-полным, если на нём можно реализовать любую вычислимую функцию)
Что не делает равноудобными для конкретных задач хаскел, джаву и Brainfuck.

Рефлексия же часто является палочкой выручалочкой когда нет времени на проектирование или рефакторинг для встраивания новой функциональности. Рефлексия в идеале - это средство добавления удобств динамических ЯП в статические.
Но мы отклонились от темы.

Rubanets Myroslav комментирует...

2Skynin
с вашего позволения я утащу в цитаты ( уж больно понравилось ):
"Рефлексия же часто является палочкой выручалочкой когда нет времени на проектирование"