Пользователь
Квазицитирование (quasiquotation) — это технология, обычно используемая в Lisp для создания программ, генерирующих другие программы. В статье объясняется механизм работы квазицитирования, поясняется почему он работает именно так и каковы его ограничения, а также даётся экскурс в историю квазицитирования.
Программист обязательно ставит на тумбочку у кровати два стакана: один полный, на случай, если он проснётся и захочет пить, а другой пустой — вдруг он не захочет. Так гласит известный анекдот. Но в реальной жизни часто работают законы Мерфи, и предусмотренные планы рушатся. Что же делать программисту на случай, если он проснётся и не поймёт, хочет он пить или нет
Сразу прошу прощения за несколько надоевший всем стиль «lytdybr», но уж очень хочется поделиться крайне приятным опытом и рассказать о по-своему замечательном компиляторном курсе. И это ещё хорошо, что я пишу сейчас, когда эмоции подугасли, а не когда я только закончил вторую главу курса и от эйфории чувствовал себя как «хомячок, которого капля никотина разрывает на части»! Сразу предупреждаю, наверняка для кого-то эта заметка — «ребёнок познаёт мир», тех прошу сразу закрыть вкладку и не судить строго. Здесь и далее, всегда и всюду, во всех четырёх сферах прошу учитывать, что я не только не создаю компиляторы, но даже и не обучаю этому и не пишу методички! ;-)
Все мы знаем замечательную игру Quake, начавшую эру 3d шутеров с полностью трёхмерным миром. Многие из нас, конечно, больше знакомы с внутренностями — превосходным игровым кодом этой игры, чем с ней самой. За это большое спасибо Джону Кармаку, открывшему исходный код движка idTech 2. Благодаря лицензии GPL, прекрасному качеству архитектуры и кода движка, появилось множество открытых игр, таких как UrbanTerror, OpenArena, The Dark Mod и других. Скорее всего, многие из нас что-то где-то подпиливали в этих или других играх, основанных на открытых движках idTech №. Мне лично в какой-то момент довелось немножко коснуться ныне забытого Warsow (qfusion, базируется на idTech 2).
Но Quake — это не только код на C, это ещё и уровни. Как это ни удивительно, но последние лет 10 они выходят с завидной регулярностью. Да ещё какие уровни!
И здесь, и в других местах в Сети есть масса статей, пропагандирующих автоматическое тестирование вообще и unit-тесты в частности. В статьях расписываются преимущества тестирования, использование его для устранения хрупкого кода, увеличения качества, миграции со старых систем на новые, рефакторинга. И, одновременно, нигде почти не упоминается об их недостатках, а ведь в инженерии нет "серебряных пуль"!
На самом деле "серебряные пули" есть, но их изобрели ещё первые инженеры, и они воспринимаются нами как скучные банальности: "мойте руки перед едой", "вытирайте ноги", "структурируйте код", "не пишите без отступов", "локализируйте состояние" и т.д. Тем не менее, тесты — это не "серебряная пуля", а один из эффективных и широко используемых инструментов, а значит, у него есть недостатки.
В этой заметке я попытаюсь структурировать и выписать именно недостатки тестов, в основном юнит-тестов. О достоинствах я постараюсь не писать, ведь об этом уже и так много материалов, только руку протяни. Разумеется, где-то я неизбежно что-то важное забуду, а где-то буду чересчур сгущать краски. Поэтому просьба рассматривать эту статью скорее как приглашение к беседе, чем что-то законченное. С моей точки зрения тема вполне назрела, и поэтому очень хотелось бы её обсудить в деталях.
Почему функциональное программирование? Так тестируем же мы почти исключительно функции.
Языки Ocaml и Haskell ведут родословную из языка ISWIM, описанного в знаменитой статье Питера Лендина "The next 700 programming languages". В ней автор, отталкиваясь от языка LISP, создаёт новый язык программирования и, в частности, вводит ключевые слова let, and и where, которые широко используются в языках семейства ML. Рано или поздно у всякого пытливого ума, занимающегося функциональным программированием возникает вопрос: почему в Ocaml не прижилось ключевое слово where, широко используемое в Haskell?
С моей точки зрения, это, в основном, обусловлено различиями в семантике этих языков, а именно императивно-энергичным характером Ocaml и чистотой-ленивостью вычислений в Haskell (которые непосредственно и жёстко связаны с impure/pure характерами этих языков).