Weekly linkdump #170

Интересные ссылки за неделю:

Замечательнейшая статья о том, как самые «простые» проблемы computer science ждут своих героев, Codekana blog " On the Speed of Light, Innovation, and the Future of Parsing
Обзор конкурента Amazon Web Services, Обзор Mosso Cloud Servers
Отзывы о завершемся недавно конкурсе для программистов Sapka, Отзывы " Sapka Contest
Самый практичный туториал по Haskell, Скрипты на Хаскеле
Сервис для генерации симпатичного резюме в html/pdf, Создай успешное резюме! / getCV.ru
English — язык общения для разработчиков всего мира, так? Так оно и есть конечно, но есть ньюансы. На родном языке люди общаются всегда эффективнее, даже разработчики, Mandarin Chinese programmer communities
Видео с конференции PyCon 2009 начали выкладывать онлайн, PyCon on blip.tv
На YouTube появился раздел EDU, с образовательными видео-материалами от ведущих университетов мира, YouTube — EDU
Темплейтный язык, работающий на клиент-сайд и сервер-сайд, Introducing JSON Template
Рассказ журналиста о разработчиках Google V8 в пасторальной Дании, FT.com / Weekend / Reportage — The genius behind Google’s web browser
Матрица компетенций для разработчиков, Programmer Competency Matrix
Как оценивают резюме в отделе HR и как его оценивают ваши коллеги-разработчики, resume_comic.png

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

Maksym Iemelianov 21.09.2010 03:26

максимализм свойственен нашим именам, тёзка:) нет, из подхода вовсе не следует отсутствие проблем в программировании, даже при наличии светлой головы и большого мастерства труженика этой области.а неопытность — так ведь учеба не кончается никогда. в чем-то я считаю себя спецом, в чем-то — абсолютно не разбираюсь.

Відповісти

Підтримати

Maxim Kizub 21.09.2010 03:26

Maxim Yemelyanov: Очень аргументировано. Особенно подкупает сам подход. Следуя ему, мы легко поймём, что проблем в программировании вообще нет, надо только правильно организовать код в своей голове и файле.Боюсь только, что эта степень максимализма выдаёт вашу лёгкую неопытность.

У парсинга просто нет будущего.звучит довольно пафосно:) возможно, SOP подходит для SymADE. зато он не подходит для общего случая....такие языки как Forth, Lisp... ...Возможно, в частности не пошли и потому, что при написании небольших и средних проектов — мета-программирование не особенно и нужно.не пошли совсем не поэтому:), а если кому-то нужно метапрограммирование, то соорудить его на большинстве ЯВУ труда не составит, это лишь вопрос организации своего кода в голове и файле.

anonymous 21.09.2010 03:26

Максим: Большое спасибо за объяснения, вроде понял. Любопытно посмотреть на структурный редактор удобнее моего любимого текстового;).

Леша Маслов: Ты совершенно верно всё написал. Преобразования текста в AST — это парсинг. И пока текст не закончен, распарсить текст (преобразовать его в AST) нельзя. А нужно. Так как IDE в процессе набивки текста должно тебе предоставить определённый сервис, вроде подсветки синтаксиса, автокомплита, или фоновой компиляции и пр. Чтоб это сделать, IDE надо догадаться, что имеет в виду программист, пока набивает текст, а не как парсер компилятор, который имеет дело с уже набитым и законченным текстом. Поэтому парсер IDE намного сложнее, завязан на конкретный язык и синтаксис, и требует сложных изменнений и длительной отладки при изменении синтаксиса.Этих всех проблем можно избежать, если использовать структурный редактор. Ему не надо догадываться, где будет стоять закрывающаяся скобка} или что-то в этом роде. Ему сразу говорят — будет блок. Он создаёт блок (внутреннее представление, узел AST дерева), отображает его (рисует {и}), а между ними уже человек вбивает что ему надо. Такой редактор не будет менее удобен, чем старый добрый текстовый редактор, просто он будет немного непривычным для нынешнего поколения программистов. Так же, как непривычно для людей, привыкших делать отступы для первой строки параграфа вставляя несколько пробелов, делать отступ в Word-е двигая ползунок мышкой или указывая его в диалоге свойств параграфа.Что до валидности текста в Word-е, то это несколько сложнее. Вот невалидный XML текст [b] bold [i] and [/b] italic [/i] . Его написать в тексте можно, но он не может быть отображён во внутреннее представление (если это XML DOM). Так Word и не даёт прямого доступа к своему внутреннему представлению. Он позволяет тебе только давать внешние коммандны — этот кусок текста выделить как bold, этот кусок как italic, а внутреннее представление он меняет сам, на основе комманд. Это позволяет ему иметь всегда валидное внутреннее состояние. Приблизительно ту-же технику будет использовать и струкутурный редактор кода программы. Код программы не всегда будет валиден с точки зрения языка программирования, но внутреннее представление (аналог AST) у программы будет всегда валидным.

Максим: Снова потерялся... Ведь в Word текст всегда валиден — это просто текст. Разве что проверить по словарю слово, и то это по-сути парсинг, т.к. слова различаются по определенным критериям ввода. В IDE все гораздо сложнее — пока я набираю текст обычно не валиден и не представляет собой синтаксически корректный программный код. А корректность кода и определяется попыткой «распознать» (распарсить) мой ввод и превратить текст в AST. Если на входе текст, на выходе — AST, то процедура преобразования — это парсинг?

Леша Маслов: Нет, в IDE ты редактируешь именно текст, и именно он и есть программа. Word не парсит документ, он реагирует на нажатие твоих кнопок, и меняет внутри себя документ. У него один документ, и много способов его показать. А вот IDE на лету строит альтернативное внутреннее представление, и с его помощью делает все эти фокусы с автокомплитом, рефакторингом и пр. Но у него уходит много сил и на этот парсинг текста — ведь ты его ещё набиваешь, он невалиден. И много сил на синхронизацию текстового (основного) и дополнительного (AST) представлений. Ведь любой из них может поменяться (или человек введёт текст или рефакторинг сделает IDE) — и надо синхронно изменить второй. А теперь сложи эти две проблемы вместе — ты набиваешь текст, его не только надо понять (хотя он ещё не закончен), но и надо решить — обновлять AST или подождать... Пишут много кода, кое-как оно начинает работать, и тут бац — новая версия C# или Java. Наша песня хороша, начинай сначала. Собственно, о проблеме парсинга в той статье и пишут. Так вот, её не надо решать методом парсинга. Заодно решается куча других проблем, появляется возможность мета-программирования уровня Lisp-а, но для любых языков, свободное расширение этих языков, создание DSL и embedded DSL. А в перспективе и возможность писать код программы компьютером.

Максим: Так я и в современных IDE редактирую внутренее представление, ведь они (IDE) на ходу парсят текст так же, как Word парсит документ. Если я ввожу данные в текстовом виде, а они преобразуются в формальное представление — разве это не парсинг?

Леша Маслов: Ты и в Word-е не текст пишешь, а редактируешь внутреннее представление документа.Так и тут, ты нажимаешь кнопки на клавиатуре, как-бы текст набиваешь, но при этом ты создаёшь/удаляешь/редактируешь узлы и их свойства.Конечно, будут и специальные кнопки, как в Word-е есть специальные кнопки форматирования текста.Конечно, атрибуты узла можно будет редактировать и в виде диалога, как в Word-е ты редактируешь свойства параграфа в отдельном диалоге.Это уже конкретная эргономика. Одно место будет удобнее редактировать так, как будто-бы это текст. Другое через диалог, или ещё что-то в этом роде. Как удобнее, так и сделают.

Максим: А писать программы как? Текстом? Или редактированием свойств узлов дерева?

Леша Маслов: В чём хитрость-то? Как нарисуешь, так и будет выглядеть. У меня AST явовского кода выглядит как ява. Специально так настраивал, поскольку привык к этому синтаксису. Но тот-же код можно отобразить и в Pascal-подобном виде, и в ML-подобном. Вот есть у тебя AST узел

node Variable { metas: array of Annotation name : string type: Type init : Expression}

Ты говоришь, рисовать его, например, как

"[" $meta "]""var" $name ":" $type ( "=" $init )? ";"

или так

$meta $type $name ( "=" $init )? ";"

или ещё как, и видишь на экране соответствующее изображение.Понятно, что это немножно сложнее, надо ещё форматирование (пробелы, переводы строк, цвета и шрифты, скобки для выражения и пр.) рисовать, поэтому спецификация отображения намного полнее, чем то, что я написал. Но ничего невозможного в этом нет. Кстати, эта спецификация выглядит почти так-же, как я написал, потому как она не текстовая, а хранится и редактируется в виде дерева, и аттрибуты (цвета, шрифты, стиль) можно редактировать или в отдельном окне, или делать fold/unfold для видимых элементов.Конечно, проблемы есть. Как были проблемы 20 лет назад с WYSIWYG редакторами. Их, тогда, собственно и не было. Использовали TeX или подобные системы форматирования. Но как-то же справились, сделали Word и прочие WYSIWYG редакторы. Так и структурные редакторы для исходного кода программ сделают. Сейчас делают — MPS (JetBrains), IP (Intentional Software), ну и SymADE. Есть и другие, менее «масштабные». Сделают в конце концов. А вот у парсеров будущего нет. Конечно, текст не пропадёт совсем. Ведь и TeX не пропал, с появлением Word-а. Просто текст будет редактироваться в текстовом редакторе, как и сейчас, а попытки «напиши парсер, который угадает, что на самом деле пишет программист» будут просто не нужны. И 90% программистов будет работать со структурными редакторами, как и сейчас 90% людей пишут в Word-е, а не TeX-е.

Максим: Хитришь, аднака;). Ведь Ant-овский XML и есть по сути AST дерево. Плюс преимущества Ant как языка программирования довольно спорны. Любопытно, как бы выглядел общецелевой (императивный) язык в виде AST дерева? Если снова глупости пишу — еще раз извиняюсь:)

Как ты AST нарисуешь, так и будет. Вот, я сейчас понемногу, в демонстрационных целях, делаю IDE для Ant-а, на базе SymADE.Вот как оно выглядит на экране (как в XML ты и сам себе можешь представить): http://mkizub.livejournal.com/

Vsevolod Dyomkin программист 21.09.2010 03:26

т.е. вот: http://joelonsoftware.com/item...

забыли самое интересное: http://joelonsoftware.com/arti...:)

Это будет хорошо работать, только если AST представление является удобным для восприятия (LISP?). В Word все проще — там дерева как такового нету — просто список с аттрибутами. Даже вложенные объекты — по сути собственные редакторы и двигать их содержимое в другие места затруднительно...Сорри за глупости, просто мысли вслух, стало любопытно -, а я мало в этом всем понимаю.

Леша Маслов: Вся его заметка в блоге — о героическом парсинге кода, когда он ещё не дописан до конца (в процессе редактирования). Вот только зачем героически парсить невалидный текст в AST, если можно редактировать прямо AST. MS Word не занимается парсингом вручную редактируемого текста (с разметкой форматирования, вроде XML). Ты просто вбиваешь в документ свой текст, по ходу дела указывая, где у тебя список, или сноска, или подчёркнутое слово. Тебе кажется, что ты редактируешь текст, а на самом деле ты редактируешь некое внутреннее Word-овское представление документа. И это представление тебе Word рендерит на экране.

Maxim: А что вместо?

Codekana blog " On the Speed of Light, Innovation, and the Future of ParsingУ парсинга просто нет будущего.

Weekly linkdump #170

19 коментарів

Підписатись на коментарі