Прочитал все комментарии и удивился, что никто про Масяню не вспомнил. У меня с рунетом тех времен три четких ассоциации — Нетскейп, Рамблер, Масяня. У последней кстати есть несколько полу-рекламных серий про сабж, называется Архивы Рунета.
На видео говорится про повороты после холмов, когда направление поворота до последнего не известно. Так что, может быть, и вправду заранее заданного маршрута нет.
Разработчик библиотеки может забить на все принципы ООП, если они противоречат главному принципу библиотеки – простоте и интуитивности использования.
А разве это же утверждение не справедливо и по отношению к «обычному» прикладному ПО?
Ведь по большому счету пользователю какого-нибудь сайта глубоко пофиг, соблюдаются ли под капотом этого сайта принципы ООП или нет. Точно так же как разработчику этого сайта плевать, как там устроены внутренности используемого фреймворка.
Если вы имеете в виду, может ли студент поучаствовать в заинтересовавшем его проекте, то да, обычно достаточно связаться с руководителем проекта. Какого-то специального регламента нет.
Контакты обычно есть на страницах проектов, если не найдете, можете написать мне, я постараюсь помочь.
Зачастую написать свой простенький DSL — это наиболее оптимальный вариант. Зачем мне универсальный комбайн, если большинство его возможностей вообще не используется?
Перечисленные вами языки (JSON, YAML, Lua) наиболее уместны в случае, когда само приложение целиком реализовано на соответствующих языках (JavaScript, Lua, ...). Да, можно использовать сторонние библиотеки для разбора, но это будет еще одной лишней зависимостью.
Изобретение собственного языка в этом случае — обычно признак проблемы «хочу показать свою крутизну».
Существующие решения мне увы не подходили, поэтому встала проблема написания собственного генератора парсеров.
А какие генераторы вы рассматривали, и чем именно, если не секрет, они вам не подошли? Ничего не имею против самой статьи, просто интересна мотивация писать парсер с нуля.
— Но, мистер Дент, проект был выставлен в городской строительной конторе. Он там лежит уже 9 месяцев.
— Ну, разумеется. Как только я узнал, я бросился туда, вчера вечером. Не слишком вы старались, чтобы мы узнали об этом строительстве. Меня, во всяком случае, могли бы и предупредить.
— Но проект можно было посмотреть и в городском совете…
— Можно посмотреть!? Да мне пришлось лезть в подвал, чтоб его найти!
— Вся документация обычно там и хранится.
— И мне пришлось взять с собой фонарь!
— Наверно, там просто нет света.
— И лестницы тоже.
— Но вы все-таки нашли проект, так ведь?
— Нашел, — сказал Артур. — Конечно, нашел. Я нашел его на дне запертого шкафа в заколоченном сортире, на двери которого висела вывеска «Осторожно, леопард!»
А разве это же утверждение не справедливо и по отношению к «обычному» прикладному ПО?
Ведь по большому счету пользователю какого-нибудь сайта глубоко пофиг, соблюдаются ли под капотом этого сайта принципы ООП или нет. Точно так же как разработчику этого сайта плевать, как там устроены внутренности используемого фреймворка.
Контакты обычно есть на страницах проектов, если не найдете, можете написать мне, я постараюсь помочь.
Зачастую написать свой простенький DSL — это наиболее оптимальный вариант. Зачем мне универсальный комбайн, если большинство его возможностей вообще не используется?
Перечисленные вами языки (JSON, YAML, Lua) наиболее уместны в случае, когда само приложение целиком реализовано на соответствующих языках (JavaScript, Lua, ...). Да, можно использовать сторонние библиотеки для разбора, но это будет еще одной лишней зависимостью.
Расскажите об этом создателям JetBrains MPS и Eclipse Xtext.
А какие генераторы вы рассматривали, и чем именно, если не секрет, они вам не подошли? Ничего не имею против самой статьи, просто интересна мотивация писать парсер с нуля.