- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
$(function () {
var objects = [
@foreach (var item in Model.PlannedObjectSet)
{
<text>{ Address: '@item.Address', Name: '@item.Name', Id: @item.Id, date: '@item.PlannedStartDate', type: @item.ObjectType, Coords: @(item.Coords ?? "null") }@(item == Model.PlannedObjectSet.Last() ? "" : ",")</text>
}
];
$('#map').tenderMap({mode:'p', zoom:10, center:[55.83, 37.58]});
$('#map').tenderMap('showData', objects);
});
Вот такая вот сериализация в JSON встретилась мне сегодня в коде Razor view
Follow us!
И кстати о наболевшем, еще одно порождение тифона и ехидны этот разорву. Сколько раз было говорено о разделении данных и представления, и тем не менее каждый уважающий себя разработчик шаблонов постарается влепить первую же пришедшую в голову копию ПХП в свой доморощеный шаблонизатор.
А как их можно совсем разделить, не скатываясь к туевой куче микрошаблонов?
А если более глобально, то проблема в том на сколько много внимания нужно уделять той или иной части. Количество внимания - функция от сложности задачи. Если шаблон тривиальный (типа просто заменить одну часть строки другой), тогда и внимание не расходуется, а если нужно вдаваться в подробности работы системы, изучать то, как она функционирует, особенно, когда для этого есть аналогичные средства в системе, в которую эта система встроена - это явная потеря времени / бесполезная активность.
И ещё я не понял про разделение данных и представления + внезапно ps/latex. Они как раз символизируют антиразделение, не?
P.S. Впрочем они даже в пыхошаблонах разделены, и передаются от пыхоконтроллера к пыхошаблону в виде пыхомассива.
P.P.S. В таких разговорах, имхо, надо бы написать определения, что у нас представление, что шаблон, что данные и т.п.
Написав свое представление ;) Сайт же, при такой схеме, предоставляет браузеру некое API с чистыми данными. Желающие могут вообще забить на представление, и читать сырой json/xml/лишь-бы-не-asn1 :)
И чем это отличается от обычного веба? 146% популярных сайтов умеют отдавать сырые данные. Архитектурно ничего нового никто не предлагает. Я люблю латех, но в вебе его видеть не хочу.
- тем, что интернет начнет меняться в сторону програм и обрабатываемых ими данных (что, собственно и происходит на умных телефонах).
Что это даст? - программы будут распространятся с лицензией (человек написавший говноскрипт для говносайта будет, теоретически ответственным за свою работу), возможно будет создать репозиторий кода для повторного использования (если пользователь один раз согласился загрузить говноквери, то не надо по сто раз в день его переспрашивать, а пользоваться уже загруженной). Поисковикам меньше работы и меньше мусора: бОльшая часть сайтов на сегодняшний день представляет из себя мусор, из которого поисковику очень тяжело выловить полезную информацию (т.как сайты чуть более чем полностью состоят из украшений, КСС3 анимаций и прочего говна).
Почему ПС/Латекс а не СГМЛ? - Да хотя бы потому, что повторяющиеся элементы не нужно тупо перечислять, а можно написать цикл! До такого идиотизма как <options> вообще не понятно как кто-то мог додуматься. Даже в брейнфаке есть циклы. ПС/Латекс больше подходят для описания графики в комплекте с текстом (ХТМЛ для этого в принципе не годится, т.как не умеет описывать графику). Такие примитивные вещи, как разбить текст на колонки - для ХТМЛя непосильная задача (к вопросу о культуре чтения / качестве полиграфии...) Ни один супер-современный, навороченный редактор не в состоянии перевести нормально макет сверстанный дизайнером в ХТМЛ (в ПС такой макет как правило переводится механически без участия дизайнера / дизайнер даже не подозревает, что ПС - это язык программирования).
слово "лицензия" появилось в треде первый раз
> если пользователь один раз согласился загрузить говноквери, то не надо по сто раз в день его переспрашивать, а пользоваться уже загруженной
CDN
> поисковику очень тяжело выловить полезную информацию
Очень просто - проигнорить теги. Понять значение этой информации гораздо сложнее, для этого люди придумали микроформаты и прочие schema.org
Интересно, как макет, всёрстанный в ps, будет смотреться на небольшом экране мобильного телефона. У меня, к примеру, есть шестидюймовый Kindle, на котором очень сложно читать pdf, а вот epub, состоящий по сути из говнохтмл, читается прекрасно.
Я говорю о такой же системе, как система из шаеред-обжект библиотек, или eggs / packages / gems и т.д.
Оооо, расскажите пожалуйста как очень просто написать поисковик!
Как же я сразу не заметил, что теги можно просто убрать, и все сразу станет на свои места! Просто потому что теги никак не соотносятся с информацией, которая в них помещена, они там для придания веса странице. Более того, скажу, что мне как-то посчастливилось иметь в своем распоряжении "Ихобот", это версия флеш плеера, написаная в Адоби в 2005 году для Гугла, чтобы сделать флеш более дружелюбным для поисковиков. Этот плеер на самом деле просто вытаскивал текс из флешки и более-менее пытался характеризовать то, что происходило в то время, как этот текст показывался. Через год-два Гугл отказались от идеи использования в принципе.
Но более поразительным открытием было то, что проблема не присуща технологии, а присуща явлению: чем сложнее программа, тем больше внимания и ненужной информации уделяется самой программе, а не содержанию. Когда стало появлятся больше сложных ХТМЛ сайтов, проблема не применула появится и там. Поисковики в очень большой степени страдают от того, что содержание не отделяется от элементов оформления, технических деталей программы (типа сообщений об ошибках, помощи по пользованию программой, декорации и т.д.) И проблема именно в том, что ХТМЛ и его недоделаные братья - учень убоги в архитектурном плане и не позволяют нормально отделить данные от представления.
Во-воторых, огромный плюс в том, что программист и дизайнер могут работать параллельно над макетом. В традиционной схеме изготовления ХТМЛ сайтов, сначала дизайнеру нужно полностью сверстать макет, а потом программист должен его нарезать, прикрутить скрипты и т.д. Не дай бог дизайнеру внести какие-то правки после того, как он сдал макет - это ж программисту переделывать кучу работы. В отличие от этого, например, AI (Adobe Illustrator) это просто алиас для ПостСкрипт, на самом деле это один и тот же формат. Работая из графической среды дизайнер может продолжать разрабатывать макет параллельно с программистом, не мешая друг другу.
ПостСкрипт позволяет использовать все типичные для программирования техники для сокращения и упрощения рабочего процесса. В нем нет необходимости каждый раз писать бойлерплейт код, как в ХТМЛ. Можно написать функцию, можно написать цикл, макрос, который интерпретирует среда.
ПостСкрипт проще реализовать, чем Си-подобные языки (и уж подавно проще, чем реализовывать 3 разных языка).
ПостСкрипт не навязывает ДОМ как модель представления графических документов, для которых эта модель вообще не подходит. Графическим документам свойственны повторяющиеся элементы, визуальная компизиция, которую тяжело представить в виде иерархии (наложения, движение).
ПостСкрипт более дружественно относится к потоковой обработке: можно отображать страницу по мере загрузки, чего практически никогда нельзя добиться в ХТМЛ.
Так масштабирование-то как раз и мешает натянуть pdf на маленький экран. Тут нужен reflow текста, а не рисование векторов на виртуальном экране.
> программист и дизайнер могут работать параллельно над макетом
Как именно они могут это делать? Кто обеспечивает интеграцию их трудов? Как она выглядит?
Как именно могут работать программист и дизайнер? - используя один и тот же файл, через систему контроля версий. Программист может работать с ним через текстовый редактор, дизайнер, через тот же Иллюстратор / КорлДроу / Фотошоп.
А история на самом деле гораздо проще. ПС был придуман и разработан специалистами, которые понимали, что нужно графику, и сделали годный инструмент. ХМЛ и говно того же разлива было придумано долбоебами менеджерами по продажам, которые нихера не понимали ни в оформлении, ни в программировании: прочитали какую-то модную статью, слепили паверпоинт презентацию и продали замечательную идею за дохуя денег. Я такое много раз встречал.
На кого бы вы не учились, pdf на моей книжке всё ещё смотрится как говно, как его не скалируй.
Скажу по секрету, очень забавно читать комменты "весь мэйнстрим - говно, слушайте, как надо делать, я читал" от человека без профильного образования, который год назад не знал, как устроены примитивные структуры данных (да, я о авто-расширяющемся массиве), демонстрировал "глубокие" познания в школьной теории чисел и комментов 300 пытался всем доказать абсолютно неверное решение простенькой задачки по терверу.
> было придумано долбоебами менеджерами по продажам
я считал общеизвестным факт, что говнохтмл разработал британский учёный (tm) Бернерс-Ли для публикации научных статей. Он даже не хотел включать <img>.
ПостСкрипт - это язык программирования, больше всего похож на Форт или чуть-чуть на Луа. ПДФ, это как дамп базы данных, (проприетарные адобовские версии могут встраивать Адоби ж.скрипт, но это не стандартно / другие вьюеры это воспроизводить не будут). Адоби разработл ПДФ во время борьбы за большой государственный подряд на хранение документов, а ПостСкрипт был ими разработан для решения практических задач, типа управления принтерами. И только в каких-то очень поздних версиях появилась программа "Акробат Дистиллер", которая конвертировала из ПостСкрипт в ПДФ. Что было политическим решением, никак не оправданым технологически. Т.е. вместо того, чтобы развивать ПостСкрипт, Адоби решили развивать ПДФ, т.как верили, что за него им когда-то заплатят.
То, что Бернерс-Ли придумал ничего не значит. Он его не продавал и не внедрял в производство, возможно получил какие-нибудь 1К американских долларов за патент / копирайт, и на этом для него все закончилось. Продавали его всякие мудаки, которые продавали части Микрософт тулчейн, которые продавали сановские / оракловские / айбиэмовские / хьюлид-пакартовские интерпрайз-солюшены.
Когда я на почте служил ямщиком работал в НИИ шелкотрафаретной печати в Киеве... только я ничего не исследовал, а заправля пленку в барабан первого в стране отечественного цифрового фотонаборного аппарата. Наша компания сотрудничала с институтом, предоставляя в качестве технической помощи меня, два 486 ПК и аренду за помещение. Институт предоставлял одного инженера с паяльником и чип, который не помещался в башню, который он все время перепаивал. В чип был встроен первый отечественный ПостСкрипт драйвер. Драйвер был естесственно пиратским, потому что Адоби официально ничего не продавали Украине. Т.е. драйвер не был откровенно спизжен, его очень долго исследовали и воспроизводили разобрав два фотонаборника... израильского производства, полу- (а как в итоге выяснилось, целиком) военной компании Скайтекс. Которые случайно оказались в Украине.
Адоби мотивировали свое нежелание продавать ПостСкрипт драйвера тем, что на гос. уровне не было фин. соглашений (но это не мешало, например, Хейдельбергу с нами торговать), мы думали, что Адоби вполне оправдано боится, что технологию спиздят как только она пересечет границу. В итоге выяснилось, что Адоби были бы рады продать, но им не позволяли гос. контракты.
Вместе с чипом в НИИ разработали графическую программу, для просмотра сгенерированых изображений, перед отправкой на печать. В лучших отечественных традициях в программе не было зума, а проверять даже А2 пленки с разрешением 3600х3600 точек на дюйм было... но зато мы были единственной компанией продававшей немцам печатную продукцию и соответсвовавшую их медицинским стандартм (наклейки на лекарства). Один из побочных эффектов работы с отечественным ПО было то, что его нужно было доводить напильником, и, как правило, перед отправкой на печать ПостСкрипт файлы доправлялись вручную (сгенерировать по-новой всю матрицу занимало часа полтора). Вот так я с ПостСкриптом и познакомился.
Не далее, чем месяц назад пошел я на собеседование по работе. Собеседователь описал картину: хочу, говорит, чтобы программа задавала топологию и всякие настройки сети, и чтобы все в 3Д! Домики набигают. Ну я смотрю, компания вроде серьезная, удивился и спрашиваю... О, но тут нужно один момент объяснить. Когда у местного спрашивают "а сможешь ли?", местные всегда отвечают "да хули тут делать, бля буду если до завтра не закончу", ну и потом десять лет со своим адвокатом бегают чтобы работодатель убытки им возместил.
Так вот, когда я удивился, и спросих а зачем сисадминам нужны модельки раутеров в 3Д, то человек сразу загорелся, и говорит такой, ну на работу я тебя, конечно, не возьму, но рассказать - расскажу. И показал написаную на Яве программу с кучей кнопочек, закладок, выпадающих меню, картами, политическими, геодезическими и спутниковой связью. Понимаешь, говорит, в чем фишка, у нас есть, замечательная программа, мы ее уже пять лет пишем, и работает офигенно, всем нравится, но, блять, 3Д нету.
На что я ему и отвечаю: смотри, ты же взрослый, здоровый человк, зачем тебе 3Д?
А он мне в ответ, понимаешь, говорит, мой менедежер получает зарплату в 10 раз больше, чем я, его менеджер, еще в 10 раз, а менеджер того менеджера продает этот продукт за сделку, если выгорит, получит денег столько, сколько сотня таких как я не получат за всю жизнь. Конкуренты сделали в 3Д, теперь менеджер, который продает наш продукт не сможет людям на глаза показаться, если 3Д нету, если у него паверпоинт не будет по тач событию картинку крутить в разных ракурсах - не продаст он ничего.
И честно, это не первый раз. Я был в таргет группе Каталиста (Адобовская разработка, подготовленная такими же менеджерами по продажам, нахер не нужная, но на которой кто-то хорошо нагрелся). ХМЛ на моей памяти столько менеджеров продавало, и всякий раз, как новая херня в нем появится, типа СОАП, а потом СОАП2, и всякие бизнес-обжекты и т.д. Куда только мир катится?
ну что за детский сад, как можно ругать соап
соап - хрень, которая позволяет внутрь себя упаковать названия методов, их аргументы и результаты так, чтобы не только все поняли, но и не испытали ни грамма проблем по автоматической генерации кода сервиса и/или клиента независимо от подлежащей технологии
благодаря soap мы на жабе ваяем полезные веб-сервисы в пару десятков методов, со сложными аргументами, за 2 дня, автоматически wsdl тупо сам публикуется, и за 2 дня противоположная сторона успевает нахерачить на условном сишарпе клиента и оттестировать его - потому что всё необходимое автоматом создаётся по одному клику мышки, остается только бизнес-логику наложить
лучше соап, конечно, rest-api, но нельзя недооценивать инертность ынтерпрайзного мышления
СОАП это история... нет, это самый лютый пиздец, кoтороый случился в одной неназваной организации, в кторой мне довелось работать. Скажем только, что проект назывался Би-Ти-Оу, что по-русски значит бизнес-что-то-обжект, а его подпроект, в котором работал ваш покорный слуга назывался Эф-Пи-Эй, что по-русски значит файненшал-планнинг-аналист.
И вот сконструировали они в одном неназваном отделе схему из СОАП объектов, и все бы хорошо, но в релизе, после более чем полугода тестов, было выявлено, что сериализация ведет себя не на столько предсказуемо, на сколько ее могли предсказать опытные инжинеры. Врезультате, один из отделов занялся производством ласт-миньют-пэтч, который, есстесственно только усугубил ситуацию. Но не беда, т.как ынтырпрайзный клиент никогда самолично продукт не запускал, продуктом оперировали специально обученые ынтырпрайз-мартышки-кнопконажиматели, и работа по предотвращению ошибок ынтырпрайзных решений лягла на хрупкие плечи ничего не подозревавшей индийско-пакистанской молодежи.
Проблема разрасталась как раковая опухоль: каждый следующий ласт-миньют-патч увеличивал количество кода обрабатывая нештатные ситуации сериализации. Невозможность повторного использования и глобального применения однотипных изменений привела к катастрофической ситуации. И тут свершилось! Сначала уволили группу мартышек в славном городе Исламабаде, потом добрались до Сан Паоло, заглянули и в Тель Авив, и выпустили новый ласт-миньют-пэтч, в котором СОАПа было в два раза больше. Т.как никому больше не хотелось терять работу. Все проверили и оттестировали. После этого патча меня тоже уволили... и я не знаю, чем дело закончилось :)
какое отношение имеет библиотечная реализация транспорта и враппинга объектов к тому, что наваяли бездумные мартышки
"операционная система - это самый лютый пиздец, который со мной когда-либо случался. если бы я не запускал фотошоп в операционной системе, то ничего подобного бы вообще не случилось!!! меня уволили из-за этого, да и брат умер"
АМФ - судя по педивикии, построен поверх soap, но при этом только для флеша
и главное, что же такого плохого в соап, если остальное сказка, если для соап на жабе ты просто берёшь пару обычных объектов, которые тебе нужны как обычные аргументы методов другого обычного объекта, добавляешь к ним всем аннотаций по минимуму - и ты уже получил готовый веб-сервис, который себя умеет декларировать, вызывать, проверять число и типы аргументов - делать то ничего не надо
а внутри (если уж так захочется посмотреть результат, который гоняется по сети) генерится вполне себе немногословный xml, доступный и понятный для простого взгляда
АМФ на клиенте нельзя воспроизвести в ж.скрипте, но на сервере можно в чем угодно. И если сравнивать с другими изкоробочными вариантами, то, например, Питон / ПХП хуже. В Яве изкоробочного аналога нет. Так что, например, если нужно от одного сервиса на Питоне послать сообщение другому сервису на Питоне, то АМФ - вполне себе подходящее решение. Его не используют потому, что не знают... многим элементарно в голову не приходит, что это возможно.
Но самая лучшая характеристика АМФ - если есть хоть одна ошибка в протоколе, хоть одно несовпадение, она будет выявлена моментально.
Главная проблема ХМЛ в том, что он оставляет очень много простора для ошибок. WSDL отдал одно описание, а на самом деле сервис отдал чуть-чуть непохожий ХМЛ? - пока эта ошибка что-нибудь испортит пройдет несколько циков тестирования. Случайно послать ХМЛ в однобайтовой кодировке? - на моей памяти ни разу без этого не обошлось. Кто-то хочет видеть БОМ, а у кого-то от этого наступает шок. Кто-то правильно реализовал стандарт, где амперсанд отделенный пробелами не энкодится, а кто-то расценивает это как ошибку... после полугода стабильной работы. А как на счет xml:space="preserve"? А некоторые парсеры не согласятся вообще видеть аттрибуты в xml неймспесе, а некоторые не позволят процессинг-инструкции перед узлом-документом. Согласно стандарту подчерк не может быть первым символом в имени узла - но большинство парсеров клали на стандарт. А еще мультибайтовые строки в названиях узлов...
> wsdl одно, а сервис - другое
ССЗБ, можно, конечно извратиться и разделить неразделимое, но зачем
> однобайтовый xml
encoding для трусов?
в любом случае, это претензии к парсеру/генератору xml, который обязан это из коробки
а если конкретный не обязан, то это должно быть четко известно разработчику, ССЗБ
> бом, стандарт - смотри выше
> мультибайтовые строки в именах
ССЗБ
> ошибка выявлена моментально
все клиенты, которые я писал на мерзкой жабе, по дефолту самостоятельно лезут на сервер за wsdl каждый раз, когда неуверены - что позволяет им все что нужно уточнить и перепроверить
т.е. примерно в половине примеров претензии такие, что заставляют задуматься о качестве работы с xml во флеше или глючной реализации соап - флешепроблемы на флешепроблемах, ради чего адобе как всегда решило изобрести очередную проприетарную хрень
не заметил в amf ничего про передачу метаданных - где можно посмотреть какие поля обязательные, какие опшионал, какие типы у них, перечисления, ограничения и тд - на педивикии это решили не раскрывать
БОМ - не стандарт вообще-то, и прогрессивное человечество старается от него уйти, но многие реализации его требуют.
Энкодинг нужно всегда проверять, это не самоочевидно из исходника, в какой он кодировке. i11n / i18n делается всегда в последнюю очередь и делается людьми, которые плохо говорят на всех языках на которых говорят разработчики проекта.
Кроме того, в проектах на Яве принято использовать .property файлы, а они по стандартну, однобайтовые...
Генерация элементов ХМЛ, типа имен узлов часто происходит динамически, и тестеру сложно представить весь допустимый диапазон того, что может сгенерировать программа и как это относится к тому, что парсер сможет переварить. Еще хуже, когда один парсер сможет переварить больше, чем другой. Или, еще веселее, когда другой парсер понимает какие-то нестандартные вещи, и они для него имеют какое-то специальное значение. Например, Микрософт одно время продвигали "." в ХМЛ именах, как разделитель чего-то там. Замл, например, точки специально обрабатывает. Ну и когда такой парсер случайно получит вполне невинное имя узла, он может его интерпретировать совсем не так, как ожидалось.
Вобщем, смысл в том, что не смотря на то, что ХМЛ на первый взгляд - простой формат, на самом деле он просто херово спроектирован. В нем есть много неочевидного. Его типы очень плохо соотносятся с типами существующим в языках программирования. С другой стороны, его выразительность минимальна. Как правило в нем нет возможности адекватно выразить бОльшую часть типов данных с которыми должна работать программа.
Что? В нем есть типы?
Вот скажите, нафига нужны пространства имен xml?
Для того чтобы не было конфликтов имен, если за разные части хмл отвечают разные люди из разных контор.
Ваш кэп.
Зачем вообще в с++ лямбды, если мне 40 лет и я вожу самосвал?
Ааа!!! Чаем подавился.
Давно подметил, у анонимба такой стиль общения: ты ему про Фому, а он тебе про Ерёму. Как будто вообще не читает что ему пишут.
>>Зачем мне SICP, если ФЯ не используются нигде кроме /pr?
Древесноволокнистая плита. Для нее неймспейсы явно не нужны.
Чуть подробнее, на небольшом примере.
Допустим НаноСофт™ придумал некий Фрейморк®, в котором формы описываются в XML, и на данный момент там нет тега <button>.
Вася и Петя независимо друг от друга решили восполнить этот пробел, и запилили свой <button>. Одновременно с этим НаноСофт™ внял просьбам пользователей, и тоже запилил тег <button>. После чего уже никто не мог понять, какой же button имел в виду автор xml'ки :)
Неймспейсы решают эту проблему так - НаноСофт™ использует неймспейс http://nanosoft.com/framework, Вася использует http://vasya.com/блаблабла, Петя - http://petya.ru/foobar. Тем самым мы всегда можем сказать, какой именно <button> имеется в виду.
И этот вопрос задаёт человек, пишуший на python.
import this, товарищи.
Ээ чо?
сколько вас там под одним акком сидит?
RELAX NG is also an International Standard (ISO/IEC 19757-2). It is Part 2 of ISO/IEC 19757 DSDL (Document Schema Definition Languages), which is maintained by ISO/IEC JTC1/SC34/WG1.
Не в W3C, да. А причина скорее всего не в глобальном заговоре, а банально в том, что relax ng появился на несколько лет позже схемы, когда инфраструктура уже была в пользу схемы. Worst is better в действии.
Жаль, мне rng больше нравится.
С другой стороны, лучше избавлятся от ХМЛ вообще, и как говорит Дан Деннет, кажется, если что-то можно не делать, то это же можно сделать плохо.
Да, мое понимание такое, что стандартизировали только ХМЛ-подобный синтаксис, а БНФ не стандартизировали. Я просмотрел стандарт, вроде так и есть, но я не вдавался в подробности.
Потребители xml - в основном суровый ынтерпрайз, а там десять лет - это один миг. На самом деле, даже xml в интерпрайзе - очень хорошо, ибо приличная часть коммуникаций всё ещё осуществляется через передачу текстовых файлов с полями фиксированной ширины через ftp.
А наличие схемы - это вообще счастье, ибо всегда можно ткнуть в схему носом и найти виноватого, но, к сожалению, формат чаще передаётся из уст в уста из поколения в поколение.
в израиле, конечно, много софтверных компаний, но разве это причина себе позволять туда-сюда бегать?
Мы успешно сдали продукт в срок, а потом нам сказали, что это была последняя версия, и больше разработки не будет, всем можно расходиться, ну типа так.
Постскрипт лучше тем, что это язык программирования, т.е. он описывает программу в терминах программы, а не частично интерпретирует, частично че-то там выполняет, а частично из заготовок берет.
Гуглопоисковик по-ходу все равно должен и стили загрузить и даже ж.скрипт выполняет в ограниченном количестве, чтобы разорбраться с тем, что происходит на странице. Так бы пришлось только один язык выполнять.
Почему не состоялась семантик-веб-три-ноль? Потому что ХТМЛ и его недоделанные друзья не умеют и не научились (несмотря на то, что их изобретатили били себя пяткой в грудь) отделять данные от отображения. (Ну, правды ради, там еще других проблем было много, но об этом вы узнаете в следующих выпусках).
ПС. а кто сказал, что в Постскрипте нельзя обработать события ввода / вывода? Все можно при желании. Опять же, никто не говорит, что нужно останавливаться на конкретной редакции стандарта, и конкретном языке, главное - правильно выбрать направление.