суббота, 29 августа 2009 г.

[comp.flame] Продолжение темы о нетбуках, нативных языках и старых временах

Заметка “Вернут ли нетбуки старые-добрые времена?” к моему удивлению и удовольствию вызвала активное обсуждение. Что приятно. Но я не раскрыл в ней всех причин, подтолкнувших меня к ее написанию. Благодаря комментарию Skynin, я решился развить эту тему.

Но прежде, чем углубиться в основное повествование, скажу пару слов по поводу:

Давно наблюдаю, как "нативные" программисты живут в каком-то
кошмаре "конца света", "последних времен" (Хорошие времена были...
прошли... Кали-Юга...) и потому светлом и напряженном ожидании
пришествия спасения в виде "C++ + Qt". (у "функциональщиков" схожее
ощущение - императищина гниет, ...). С психологической точки зрения
вызвано ощущением - "маргинальности", и "аутсайдерства".

Чувство маргинальности, несомненно, присутствует. А вот чувство аутсайдерства -- нет :) Но больше меня волнует тенденция постоянного расслоения программистов по прикладным специализациям. В начале 90-х мне казалось, что программист легко может менять языки программирования и проекты – сначала заниматься задачами реального времени на автокоде Эльбруса, затем делать бухучет на FoxBase в MS-DOS, затем ГИС под Windows, затем драйвера под Linux… Но время идет. И теперь сложно даже представить, сколько усилий Web-программисту потребуется, чтобы переквалифицироваться в драйверописатели или АСУТП-шники (и наоборот). В 90-е годы далеко не каждый программист был способен на это – только самые лучшие. Они и сейчас могут это сделать. Но сейчас барьер при переходе из одной области в другую очень высок и он все время растет. Поэтому, чем дольше я специализируюсь в своей нише, тем больше беспокойство я испытываю, когда думаю, что какой-нибудь большой приплыздец случится… В общем, специалист подобен флюсу, как говаривал Козьма Прутков.

Ну а теперь вернемся к нейтиву и не нейтиву (то бишь native code vs managed code). Прежде чем продолжать разговор, нужно определиться, что будет считаться нативным кодом, а что не будет. Я не спец по определениям, поэтому здесь у меня возникли изрядные трудности. Java уже давно не простой интерпретатор, а .NET (насколько я помню) никогда им и не был. И для Java, и для .NET существует возможность предварительной компиляции в нативный код (для Java в виде GNU-того компилятора, для .NET, если не ошибаюсь, встроенный во фреймворк Ngen). В тоже время для нейтива разрабатывались подходы, когда после компиляции строится объектный код некоей виртуальной машины, преобразуемый в родной код конкретной платформы при развертывании приложения. Так что граница между нейтивом и не нейтивом уже давно сильно размыта. А в контексте данного разговора я проведу ее следующим образом:

Нейтив подразумевает запуск на исполнение родного для конкретной платформы кода без помощи вспомогательной прослойки в виде какого-нибудь фреймворка или виртуальной машины. Запущенное приложение обращается к функциям ОС, а не к функциям базового фреймворка. Приложение содержит в себе все необходимые части и сторонние динамически-загружаемые библиотеки и не требует для своей работы установки какого-либо базового фреймворка/виртуальной машины.

Сразу подчеркну, что я не являюсь противником управляемого кода. Более того, я даже в чем-то любитель управляемого кода (порядком и с удовольствием попрограммировал на Ruby). Управляемый код очень хорош во многих случаях. Например, скрипты. Одним из самых важных достоинств моей системы сборки Mxx_ru для меня является то, что ее исходный код всегда присутствует и доступен для быстрой правки, если вдруг на какой-то машине что-то пошло не так. Еще один пример: server-side системы режима 24x7. Организовать в них “горячую замену” кода на управляемом динамически-типизированном языке (типа Erlang, Ruby или Python) гораздо проще, чем на статически-типизированном. Или, к примеру, возможности для метапрограммирования, которые есть в Ruby и Python как-раз из-за того, что это управляемые языки. Хотя, чем больше используется управляемого кода, тем больше ресурсов потребляют приложения. Этого не отнять.

В принципе, всему есть свое место – и нейтиву, и не нейтиву. Если без фанатизма. А вот фанатизм, имхо, таки присутствует. Что наблюдается в ползучем распространении Java/.NET, Ruby, Python, JavaScript, Flash, …, you name it. А так же тем, что в области нейтива за последние 15-20 лет не возникло ни одного успешного C++киллера (ну не считаю я таковыми ни Eiffel, ни Ada, ни OCaml, ни D, ни Haskell).

И тут самое время задаться вопросом: “Если C++киллера так и не появилось, то нужен ли он вообще и зачем?” В эту же тему очередная цитата из комментария Skynin:

Если программист готов бесплатно "заморачиваться эффективным и компактным приложением" – пусть изменит мир.

Собственно, в этом все дело. Мне действительно хочется, чтобы мир изменился. Поскольку то, что в нем происходит сейчас мне не кажется нормальным. Складывается впечатление, что производители делают “то, что можно сделать”, а не то, что “хотелось бы иметь” пользователям. Пара примеров.

Летом в стиральной машине полетел насос. Вызвали мастера, он его заменил. Спросил, сколько лет машине. Семь, отвечаем. Ну понятно, говорит, почти евростандарт – современные бытовые приборы (холодильники, стиральные машины, телевизоры и т.д.) расчитаны на семь лет эксплутации. Мол производителям выгоднее менять линейку продукции раз в несколько лет, а покупателям проще выбрасывать 4-5 летнюю технику и покупать совершенно новую, чем выпускать модели, способные работать по 15-20 лет.

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

В области персональных компьютеров для меня явно выделялись две стадии – когда их мощность была явно недостаточной и когда их мощность уже достигла видимости достаточности. Первая стадия очень хорошо просматривалась во время гонок 86, 286б 386, 486, 486DX-2, 486DX-4, P-I-66, P-I-100,…, P-I-200-MMX, P-II, P-III. До 486-х скорость была явно недостаточна. Скажем 200-страничный документ в Word-е на 486 еще как-то можно было написать, а вот на 386 – уже фигушки. И где-то до P-II рост производительности компьтеров явным образом наблюдался. Переход на новую железку сразу сказывался на повышении скорости работы и ее комфортности (музыку в фоне можно было слушать, несколько процессов параллельно работали не тормозя друг друга, потом видео появилось). Но где-то с рубежа P-II или P-III стало заметно, что такого серьезного прироста скорости/комфортности работы при смене компьютера уже нет (очевидно, из-за нового софта). Начался выход персоналок в категорию “достаточно производительных”. Если до P-IV имело смысл менять железо раз в год-полтора, то сейчас это не так. Для многих классов задач возможностей существующих машин уже хватает и даже с запасом. Т.е. игры или HPC все еще насилуют процессоры/память/видеокарты по полной программе, но вот для “бытовых” нужд (электронная почта, интернет, skype, офис,…) вполне хватает даже P-IV с 2Gb RAM.

Т.е. в области персоналок уже складывается ситуация, когда пользователю не нужно менять железо раз в год для того, чтобы его почтовый клиент не тормозил. Производительность перестает быть главным критерием выбора нового компьютера/ноутбука. А раз так, то не начинается ли пора, когда человек покупает себе машинку не на 2-3 года, а на 5-6-7-и-более лет? И если она начинается, то нужно ли разработчикам задумываться о том, чтобы экономить ресурсы пользователя?

Мне кажется, что нужно. Причем, под ресурсами здесь понимается не только использование процессора и памяти пользовательской машины. Но и объем скачиваемого дистрибутива (вы бы выбрали аудиоплейер с дистрибутивом в 2Mb или в 22Mb, или в 222Mb?) и объем сопутствующих виртуальных машин/фреймворков.

А если нужно экономить ресурсы, то как это сделать? Например, использовать нативные языки программирования. Которые, (нормальными руками) позволяют делать быстрые и компактные программы. Не требующие сторонних многомегабайтных дистрибутивов. Быстро стартующие, оперативно откликающиеся, экономно расходующие ресурсы (я набираю этот текст в Windows Live Writer-е, который на Core2Duo 2.4MHz с 4Gb памяти стартует секунд 10, а затем отжирает 55Mb памяти и работает не очень шустро, да и подглючивает). /Примечание. На более совершенном, чем C++, языке это вполне возможно и с такими же трудозатратами, как на управляемых языках. На C++ возможно то же, но это сложно. Так что речь не о C++./

Еще один вопрос: а верю ли я сам в то, что подобный разворот событий произойдет? Что пользователи будут покупать компьютеры на 10 лет? Что они будут работать в одной и той же версии своей любимой программы в течении нескольких лет (т.е. эпизодически это уже и сейчас происходит, но не массово)? Что пользователи будут смотреть, жрет ли программа 10Mb во время работы или 100Mb?

Не сильно, но хотелось бы. Ведь в конце-концов должны же мы начать считать свои и чужие деньги. Вон за океаном, многие не думали про бесплатный сыр в мышеловке, брали и давали кредиты без оглядки. Сейчас оказались в заднице, и не только они. А все по той же причине – позволяли себе то, что можно было позволить, а не то, что следовало бы…

При чем же здесь нетбуки? Да так – отличный повод разработчикам начать задумываться о ресурсах пользователя ;) Ну и поворчать о старых-добрых временах ;)

пятница, 28 августа 2009 г.

[comp.netbook] 5-ти дюймовый нетбук от Sharp

Вот какая уникальная железяка:

Размер: 161.4 x 108.7 x 19.7-24.8mm, вес 409g.
Процессор: Freescale i.MX51 (ARM), 800MHz.
RAM: 512Mb, HDD: 4Gb Flash (2Gb свободно) + возможность использования Micro SDHC карточки.
Дисплей: 5-дюймовый, сенсорный, 1024x600.
OS: специально допиленная Ubuntu 9.0.4 for ARM.
Еще: 802.11b/g Wi-Fi, один нормальный USB 2.0 разъем и один mini USB.

Похоже, Sharp хочет возродить подобие Zaurus-а.

Кому и нафига оно нужно – я не представляю. Видел когда-то в метро у парнишки Zaurus. Он на нем в Midnight Commander сначала исправил какой-то C-шый исходник, а затем запустил gcc для компиляции. Все это делалось на небольшом экране и шрифт был таким маленьким, что мне показалось это занятием для мазохистов. Лично я считаю, что экраны меньше 8.9” – это не серьезно. Ничего на них толком не увидишь и не сделаешь.

четверг, 27 августа 2009 г.

[comp.bugs] Статья о разработке игр, которую имеет смысл прочитать

Статья: Dirty Coding Tricks (по наводке thesz). Это сборник небольших рассказов разработчиков игр о том, как они “решали” проблемы в своем коде, когда до дедлайна оставалось всего ничего. Например, в одном случае версия игры для PlayStation падала, если в начале первого уровня игрок слишком долго ничего не делал. Ошибку не нашли, но обнаружили, что если в этом месте развернуть виртуальную камеру на 90 градусов вправо, то крах программы не происходит. Именно в таком варианте игру и отправили в печать.

Но на двух эпизодах я хотел бы остановиться подробнее.


Meet My Dog, Patches

История о том, как при переносе игры с PC на PlayStation-I пришлось заменить все операции с float-ами на операции с числами фиксированной точности. Из-за этого возникали погрешности вычислений в системе определения коллизий. И персонаж, например, проваливался в дырки в полу (которые так же возникали из-за погрешностей вычислений). Сначала проблему попытались решить переделкой уровней игры. Но это не помогало, т.к. сразу же после латания дыр на одном уровне, сотни новых дыр обнаруживали на других уровнях. Тогда разработчик решил пропатчить игровой движок условиями вида:

IF (Damp will fall through a hole()) THEN
Don't do it

Поначалу патчи работали. Потом их становилось все больше и больше:

But it did not go well. Hundreds of patches were needed, and then the patches themselves started causing problems, so more patches were added to turn off the patches in hyper-specific circumstances. The bugs kept coming, and I kept beating them back with patches. Eventually I won, but at a cost of shipping several months behind schedule, and working 14 hour days for all of those several months.

После такого опыта разработчик пришел к выводу:

That experience soured me against "the patch." Now I always try to dig right down to the root cause of a bug, even if a simple, and seemingly safe, patch is available. I want my code to be healthy.

К похожему выводу я пришел благодаря олимпиадам по программированию. Причем мне потребовалось две олимпиады. В 1992-м на республиканской олимпиаде в Гродно, в задаче для языка ассемблер я поленился написать общую функцию для вычленения ключевых слов из файла. В результате я запорол свое решение. На следующий год, на такой же олимпиаде и опять на ассемблере я попытался учесть опыт прошлого – самую сложную часть задачи я сначала расписал на бумаге (операции сложения, вычитания, умножения и деления для больших чисел в символьном представлении). И когда этот код быстро заработал без ошибок, я решил “сэкономить” время и оставшуюся часть (перебор чисел с их взаимным перемножением) сделать прямо за компьютером. Естественно, вторая часть не заработала и я опять провалился.

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

Мне повезло прочувствовать это на собственном горбу в раннем возрасте и на ничего не значащих проектах.


The Programming Antihero

Это история о том, как разработчики игры титаническими усилиями пытались уменьшить потребление памяти. После всех потуг оставалось где-то 1.5Mb перерасхода. И тут один матерый программирище показывает классный фокус. Открывает свой код и удаляет оттуда статический массив размером 2Mb. Который был объявлен, но никогда не использовался. Офигевшему от такого трюка коллеге он объяснил: мол, давно заметил, что память придется экономить, а делать это очень и очень трудно. Мол, практически невозможно уместить готовую игру в жестки лимит. Поэтому я всегда занимаю пару мегабайт памяти. И когда становится совсем уж невмоготу, я эту память отдаю и мы вписываемся во все лимиты.

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

Кстати, эта история напомнила мне давным-давно прочитанную книгу Роберта Хайнлайна “Туннель в небе”. Там студентов для экзамена на выживания выбросили на неисследованную планету. И предупредили, мол опасайтесь стобора. Кто такой стобор, естественно, никому не объяснили. А в самом конце, когда выжившему главному герою довелось поговорить с организатором эксперимента, выяснилось следующее:

-  Но  вначале  это  было  серьезной помехой. Эти стоборы
особенно - я  покажу вам одного  из них в  поле, когда...   но
послушайте, - Род задумчиво посмотрел на Мэтсона.
     - Это ведь стоборы,  не так ли? Маленькие  хищники, более
высокие спереди, чем сзади, несколько похожие на диких  котов,
но в десятки раз более свирепые?
     -  Почему ты спрашиваешь меня?
     -  Но  ведь  вы  предупреждали  нас о стоборе. Все группы
были предупреждены.
     - Вероятно, это и  должен быть стобор, -  заметил Мэтсон,
- но я не знал, что он так выглядит.
     -  Что?
     - Род, на  каждой планете есть  свой СТОБОР... и  все они
различны.  Иногда  их  несколько.   -  Он  остановился,  чтобы
выбить свою трубку.   - Ты помнишь,  я говорил, что  на каждой
планете есть своя особая опасность, отличная от опасностей  на
всех остальных планетах Галактики?
     -  Да...
     -  Конечно,  но  это  ничего  не  означает,  кроме  чисто
умозрительной  конструкции.  А  вы  должны  опасаться реальной
опасности,   если   хотите   остаться   в   живых...   И    мы
персонифицировали  эту  опасность,  не  говоря  вам, в чем она
заключается. Ежегодно  мы делаем  это разными  способами. Цель
заключается  в  том,   чтобы  предупредить  вас:   смертельная
опасность может выглядеть как угодно... Мы старались  поселить
страх  перед  этой  опасностью  в  ваших внутренностях, а не в
головах.
     - Ну,  и дурак  же я  ... здесь  нет никакого  стобора! И
никогда не было.
     - Конечно, он был. Для кого же вы соорудили эти ловушки?

Вот и напомнил мне 2Mb массив-гандикап в программе того самого стобора :)

среда, 26 августа 2009 г.

[comp.wow] Впечатления очевидцев от Project Natal

Найдены в Тупичке Гоблина.

Что такое Project Natal? Расскажу в двух словах то, что сам узнал буквально только что :)

 

Этот девайс с камерами подключается к игровой приставке и следит для движениями частей тела игрока. Что позволяет управлять игрой без каких-либо других устройств (пультов, рулей, педалей) и проводов. Подробнее в цитате:

В заключение был показан принцип работы сенсоров камеры и программы распознавания. Камера воспринимает как оптическую, так и инфракрасную картинку, благодаря чему может работать при недостаточном освещении. Программное обеспечение составляет из оптической, тепловой и глубинной составляющих анализа некий скелет, который повторяет каждое движение игрока. Не используя многочисленные датчики, обычно применяемые для подобных целей, система осуществляет Motion Capture в реальном времени. "Скелет" состоит из 48 элементов, охватывает голову, торс, руки, ноги и ступни. Пальцы не анализируются. Во время презентации была показана соответствующая полигональная фигура. Для отслеживания движения игрока не будет являться помехой, если часть его тела будет кратковременно заслонена мебелью или другими игроками. Система может мониторить одновременно до четырёх человек на достаточно большой площади перед камерой. Сенсоры теряют контакт лишь при удалении на четыре-пять метров.

К играм я равнодушен, но как разработчика меня интересует, что за начинка использована в этом устройстве, под какой ОС она работает (рилтайм все-таки), на чем написан ее софт и каков его объем. Может, со временем, просочится больше информации. Но кажется мне, что какое бы железо в ней не стояло, софт загружает его под плашку.

[comp.flame] Разбухание Boost-а: доколе?

Прошу прощения, что возвращаюсь к своей любимой теме – бросанием тухлых помидоров в Boost. Но повод уж больно хорош для того, чтобы показать, что мне в Boost-е не нравится больше всего. 24-го августа начался процесс review очередного претендента на включение в Boost. Что это за зверь такой? А вот:

The boost polygon library provides algorithms focused on manipulating planar
polygon geometry data.  Specific algorithms provided are the polygon set
operations (intersection, union, difference, disjoint-union) and related
algorithms such as polygon connectivity graph extraction, offsetting and
map-overlay.  These so-called Boolean algorithms are of significant interest in
GIS (Geospatial Information Systems), VLSI CAD as well al other fields of CAD,
and many more application areas, and providing them is the primary focus of this
library.  The polygon library is not intended to cover all of computational
geometry in its scope, and provides a set of capabilities for working with
coordinates, points, intervals and rectangles that are needed to support
implementing and interacting with polygon data structures and algorithms.
Specifically, 3d and non-Cartesian/non-planar geometry is outside of the scope
of the polygon library.

Прошу прощения за мой французский, но это, блин, именно та часть, которой совершенно не хватало в составе собрания универсальных библиотек общего назначения (он же Boost)! Миллионы C++ программистов по всему миру только и занимаются, что GIS и CAD системами. И теперь они могут найти в Boost-е все самое необходимое для этого. Только зачем же останавливаться на достигнутом? Нужно сразу внести ее в один из следующих стандартов языка C++!

Если же говорить серьезно, то я еще понимал назначение Boost-а, когда там кучковались shared_ptr; thread; function, bind и lambda; filesystem; random; string_algo и пр. Но после того, как дистрибутив Boost-а достиг 30Mb (т.е. больше JRE) смысл его существования и цели его создателей для меня стали совершенно непонятны. Я не могу понять, зачем мне время от времени скачивать 30Mb (31, 32, …, 40, …MB) архивы только для того, чтобы воспользоваться обновленными версиями, например, filesystem, interprocess и asio. И мне не столько жалко трафика и места на своем винчестере, сколько я не могу понять – почему это так?

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

воскресенье, 23 августа 2009 г.

[life.painting; comp.humour] Иллюстрация сложных программных систем от художника Яцека Йерка

Найдено в потрясающей подборке работ этого художника в “Блоге разнузданного гуманизма”.

Прям как большая программная система – невообразимое наслоение различных фишечек и рюшечек, возведенное абы как на явно не предназначавшемся для этого фундаменте, готовое выспыхнуть от малейшей искры и находящееся в непосредственной близости от старательно разведенных костров…