Тест вайсмана: Вымышленная формула из сериала HBO была взята на вооружение настоящими учёными

Вымышленная формула из сериала HBO была взята на вооружение настоящими учёными

Кино и сериалы

Вадим Елистратов

30 июля 2014

Коэффициент Вайзмана (Weissman Score), придуманный консультантами для сериала «Кремниевая долина» (Silicon Valley) канала HBO, был взят на вооружение настоящими учёными. Об этом сообщает IEEE Spectrum.

Сюжет «Кремниевой долины» рассказывает о программисте, который случайно придумал прорывной механизм компрессии данных и вместо того, чтобы продать права на него крупной корпорации, решил начать строить собственную компанию.

При создании шоу его сценаристы столкнулись с нестандартной проблемой: параметра, который дал бы понять зрителям, что один вид сжатия лучше другого, на тот момент не существовало. Поэтому консультанты сериала профессор Стэнфордского университета Тсаки Вайзман (Tsachy Weissman) и аспирант Винит Мисра (Vinith Misra) предложили метрику, с помощью которой можно оценивать подобные алгоритмы.

Обычно различные виды сжатия сравнивают по двум отдельным параметрам — скорости работы и качеству компрессии. Коэффициент Вайзмана включает в себя сразу оба параметра. Полученный результат нормализуется по показателям механизма сжатия, являющегося индустриальным стандартом для сжатия этого вида данных (например, FLAC для звука), тем самым делая метрику универсальной.

Сам Вайзман охотно использует свой алгоритм, пусть и сторонится славы, однако его коллеги уже начали упоминать новую метрику в своих работах. Дрон Бэрон (Dron Baron), ассистент профессора электрики и компьютерной инженерии Государственного университета Северной Каролины, верит в коэффициент Вайзмана и планирует в дальнейшем использовать его в своих работах.

Выдающийся учёный Марчело Вайнбергер (Marcelo Weinberger) из Стэнфорда уже рассматривает включение коэффициента Вайзмана в свой учебный курс, чтобы сделать абстрактный предмет более понятным для студентов и заставить их задуматься о фундаментальных проблемах компрессии и компромиссах, на которые приходится идти для их решения.

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

Премьера «Кремниевой долины» на HBO состоялась 6 апреля. 8-серийное шоу от Майка Джаджа, известного по мультсериалам «Царь горы» и «Бивис и Баттхед», получило высокие оценки от прессы и было продлено на второй сезон. 

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

#сериалы #HBO #Silicon_Valley #Майк_Джадж #Кремниевая_долина #Бивис_и_Баттхед #Коэффициент_Вайзмана #Weissman_Score #Тсаки_Вайзман #Винит_Мисра #Дрон_Бэрон #Марчело_Вайнбергер #Царь_горы #Джерри_Гибсон

О коэффициенте Вайсмана: kirulya — LiveJournal

О коэффициенте Вайсмана: kirulya — LiveJournal

?

Categories:

• catIsShown({ humanName: ‘кино’ })» data-human-name=»кино»> Кино
• Дети
• Cancel

Смотрю «Силиконовую долину» и получаю удовольствие.
Дальше пост для тех, кто в курсе.

При создании шоу его сценаристы столкнулись с нестандартной проблемой: параметра, который дал бы понять зрителям, что один вид сжатия лучше другого, на тот момент не существовало. Поэтому консультанты сериала профессор Стэнфордского университета Тсаки Вайзман (Tsachy Weissman) и аспирант Винит Мисра (Vinith Misra) предложили метрику, с помощью которой можно оценивать подобные алгоритмы. (отсюда)

Только что разговаривала с сыном, он сказал, что этого профессора-консультанта зовут Цахи Вайсман (Цахи — это нормальное еврейско-израильское имя), а его младший брат, который сейчас работает в Гугле, приятель моего сына: они познакомились много лет назад в Израиле.

Вот тебе и коэффициент Вайсмана, вокруг которого и построен весь сюжет сериала. Мир тесен, особенно если это еврейский мир программистов.

Tags: дети в Америке

Subscribe

• За этот пост я забанена на неделю в Фб

  Буду говорить Эзоповым языком. За последние два дня у меня всплеск комментов на одну тему. Будто один маленький и злобный народец сидит и потирает…

• Улучшаю мир

  В магазине узкий проход между стеллажами. Его полностью перегородила очень пожилая женщина с сумкой на тележке. Я обратилась: — Мадам, позвольте…

• Мои книги за 1 доллар

  Я, наконец-то, сделала файл с аннотациями к своим книгам. Кому надо, пишите в личку, пришлю.

Photo

Hint http://pics.livejournal.com/igrick/pic/000r1edq

• 12 comments

• За этот пост я забанена на неделю в Фб

  Буду говорить Эзоповым языком. За последние два дня у меня всплеск комментов на одну тему. Будто один маленький и злобный народец сидит и потирает…

• Улучшаю мир

  В магазине узкий проход между стеллажами. Его полностью перегородила очень пожилая женщина с сумкой на тележке. Я обратилась: — Мадам, позвольте…

• Мои книги за 1 доллар

  Я, наконец-то, сделала файл с аннотациями к своим книгам. Кому надо, пишите в личку, пришлю.

Вымышленная метрика сжатия переносится в реальный мир

Борьба, с которой сталкивается большинство компаний при поддержке кода, вызывает вторую проблему: хрупкость. Каждая новая функция, добавляемая в код, увеличивает его сложность, что увеличивает вероятность того, что что-то сломается. Обычно программное обеспечение становится настолько сложным, что разработчики избегают вносить в него изменения больше, чем это абсолютно необходимо, опасаясь что-то сломать. Во многих компаниях целые команды разработчиков работают не для того, чтобы разрабатывать что-то новое, а просто для того, чтобы поддерживать существующие системы в рабочем состоянии. Можно сказать, что они используют версию программного обеспечения
Гонка Красной Королевы, которая бежит так быстро, как только может, лишь бы остаться на одном месте.

Это печальная ситуация. Тем не менее, текущая траектория индустрии программного обеспечения направлена ​​на увеличение сложности, увеличение времени разработки продукта и повышение хрупкости производственных систем. Чтобы решить такие проблемы, компании обычно просто привлекают к решению проблемы больше людей: больше разработчиков, больше тестировщиков и больше техников, которые вмешиваются, когда системы выходят из строя.

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

При функциональном программировании меньше значит больше

Хороший способ понять
обоснование функционального программирования заключается в рассмотрении того, что произошло более полувека назад. В конце 1960-х возникла парадигма программирования, направленная на повышение качества кода при одновременном сокращении необходимого времени разработки. Это называлось структурным программированием.

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

Оператор GOTO используется для перенаправления выполнения программы. Вместо выполнения следующего оператора по порядку поток программы перенаправляется на какой-либо другой оператор, указанный в строке GOTO, обычно при выполнении некоторого условия.

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

Шира Инбар

Неспособность этих разработчиков понять, как работает их код или почему он иногда не работает, была проблемой сложности. Эксперты по программному обеспечению той эпохи считали, что эти операторы GOTO
создавали ненужную сложность, и что GOTO должен был уйти.

В то время это была радикальная идея, и многие программисты сопротивлялись потере утверждения, на которое они привыкли полагаться. Споры продолжались более десяти лет, но, в конце концов, GOTO угасла, и сегодня никто не стал бы выступать за ее возвращение. Это связано с тем, что его исключение из языков программирования более высокого уровня значительно снизило сложность и повысило надежность создаваемого программного обеспечения. Это было сделано за счет ограничения того, что могли делать программисты, что в конечном итоге облегчило им анализ кода, который они писали.

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

Обнуление проблем с нулевыми ссылками

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

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

В аппаратном обеспечении этого не происходит, потому что законы физики ограничивают возможности. Конечно, инженеры по аппаратному обеспечению могут ошибаться, но не так, как вы можете с программным обеспечением, где слишком многое возможно, к лучшему или к худшему.

Еще один монстр сложности, скрывающийся в трясине программного обеспечения, называется
нулевая ссылка, означающая, что ссылка на место в памяти вообще ни на что не указывает. Если вы попытаетесь использовать эту ссылку, произойдет ошибка. Таким образом, программисты должны не забывать проверять, является ли что-то нулевым, прежде чем пытаться прочитать или изменить то, на что оно ссылается.

Почти каждый популярный сегодня язык имеет этот недостаток. Первый ученый-компьютерщик
Тони Хоар ввел нулевые ссылки в язык ALGOL еще в 19 году.65, а позже он был включен во многие другие языки. Хоар объяснил, что сделал это «просто потому, что это было так легко реализовать», но сегодня он считает это «ошибкой на миллиард долларов». Это потому, что это вызвало бесчисленное количество ошибок, когда ссылка, которую программист считает действительной, на самом деле является нулевой ссылкой.

Разработчики программного обеспечения должны быть предельно дисциплинированы, чтобы избежать таких ловушек, и иногда они не принимают адекватных мер предосторожности. Архитекторы структурного программирования знали, что это справедливо для операторов GOTO, и не оставили разработчикам лазейки. Чтобы гарантировать улучшения ясности, которые обещал код без GOTO, они знали, что им придется полностью исключить его из своих языков структурированного программирования.

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

Как можно устранить эти недостатки? Оказывается, ответ
существует уже несколько десятилетий: чисто функциональные языки программирования.

Из дюжины языков функционального программирования Haskell, безусловно, является самым популярным, судя по количеству репозиториев GitHub, использующих эти языки.

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

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

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

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

В функциональном программировании также есть решение «ошибки на миллиард долларов» Хоара — нулевых ссылок. Он решает эту проблему, запрещая нули. Вместо этого существует конструкция, обычно называемая
Может быть (или Опция на некоторых языках). A Может быть может быть Ничего или Просто некоторое значение. Работа с Возможно s заставляет разработчиков всегда учитывать оба случая. У них нет выбора в этом вопросе. Они должны справиться с Ничего случай каждый раз, когда они сталкиваются с Возможно . Это устраняет множество ошибок, которые могут порождать нулевые ссылки.

Функциональное программирование также требует, чтобы данные были неизменяемыми, а это означает, что если вы присвоите переменной какое-то значение, это значение останется навсегда. Переменные больше похожи на переменные в математике. Например, чтобы вычислить формулу,
y = x ² + 2 x – 11, вы выбираете значение для x и ни разу во время вычисления y означает, что x принимают другое значение. Таким образом, при вычислении x ² используется то же значение для x , что и при вычислении 2 x . В большинстве языков программирования такого ограничения нет. Вы можете вычислить x ² с одним значением, затем изменить значение x перед вычислением 2 x . Запрещая разработчикам изменять (мутировать) значения, они могут использовать те же рассуждения, что и на уроках алгебры в средней школе.

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

Почему это? Это потому, что люди работали над математикой в ​​течение тысяч лет. Это довольно солидно. Большинство парадигм программирования, таких как объектно-ориентированное программирование, имеют за плечами не более полдюжины десятков лет работы. По сравнению с ними они грубы и незрелы.

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

Позвольте мне привести пример того, насколько программирование небрежно по сравнению с математикой. Обычно мы учим новых программистов забывать то, что они узнали на уроках математики, когда они впервые сталкиваются с оператором
х = х + 1 . В математике это уравнение не имеет решений. Но в большинстве современных языков программирования х = х + 1 не является уравнением. Это оператор , который дает компьютеру команду взять значение x , добавить к нему единицу и поместить обратно в переменную с именем x .

В функциональном программировании нет операторов, только
выражений . Математическое мышление, которому мы научились в средней школе, теперь можно использовать при написании кода на функциональном языке.

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

Функциональное программирование имеет крутую кривую обучения

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

Самая большая проблема с этим гибридным подходом заключается в том, что он по-прежнему позволяет разработчикам игнорировать функциональные аспекты языка. Если бы мы оставили GOTO в качестве опции 50 лет назад, мы могли бы до сих пор бороться со спагетти-кодом.

Чтобы воспользоваться всеми преимуществами чисто функциональных языков программирования, вы не можете идти на компромисс. Вам нужно использовать языки, которые были разработаны с учетом этих принципов с самого начала. Только приняв их, вы получите множество преимуществ, которые я описал здесь.

Но функциональное программирование — это не ложе из роз. Это дорого обходится. Научиться программировать в соответствии с этой функциональной парадигмой — это почти то же самое, что заново научиться программировать с самого начала. Во многих случаях разработчики должны ознакомиться с математикой, которую они не изучали в школе. Требуемая математика не сложна — она просто нова и для тех, кто боится математики, страшна.

Что еще более важно, разработчики должны научиться новому мышлению. Сначала это будет в тягость, потому что они к этому не привыкли. Но со временем этот новый способ мышления становится второй натурой и в конечном итоге снижает когнитивные издержки по сравнению со старыми способами мышления. Результатом является значительный прирост эффективности.

Но переход к функциональному программированию может быть трудным. Мое собственное путешествие, проделавшее это несколько лет назад, является показательным.

Я решил выучить Haskell — и мне нужно было сделать это в рамках бизнес-плана. Это был самый трудный опыт обучения за всю мою 40-летнюю карьеру, в значительной степени потому, что не было окончательного источника помощи разработчикам в переходе к функциональному программированию. Действительно, за предыдущие три десятилетия никто не написал ничего всеобъемлющего о функциональном программировании.

Чтобы воспользоваться всеми преимуществами чисто функциональных языков программирования, вы не можете идти на компромисс. Вам нужно использовать языки, которые были разработаны с учетом этих принципов с самого начала.

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

Когда я решил, что наша компания должна перейти на использование функциональных языков, я не хотел подвергать своих разработчиков такому же кошмару. Итак, я начал создавать для них учебную программу, которая стала основой для книги, призванной помочь разработчикам стать функциональными программистами. В
В своей книге я даю руководство по овладению функциональным языком под названием PureScript, который украл все замечательные аспекты Haskell и улучшил многие из его недостатков. Кроме того, он может работать как в браузере, так и на внутреннем сервере, что делает его отличным решением для многих современных требований к программному обеспечению.

Хотя такие учебные ресурсы могут только помочь, для того, чтобы этот переход произошел в широких масштабах, компании, работающие с программным обеспечением, должны больше инвестировать в свой самый большой актив: в своих разработчиков. В моей компании,
Panoramic Software, где я являюсь техническим директором, мы сделали эти инвестиции, и вся новая работа выполняется либо на PureScript, либо на Haskell.

Мы начали переходить на функциональные языки три года назад, начав с еще одного чисто функционального языка под названием
Elm, потому что это более простой язык. (Мы и не подозревали, что в конце концов перерастем его.) Нам потребовалось около года, чтобы начать пожинать плоды. Но с тех пор, как мы преодолели горб, это было замечательно. У нас не было ошибок рабочего времени выполнения, которые были так распространены в том, что мы раньше использовали, JavaScript на передней части и Java на задней. Это улучшение позволило команде потратить гораздо больше времени на добавление новых функций в систему. Теперь мы почти не тратим время на отладку производственных проблем.

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

Будущее функционального программирования

Моя компания небольшая. Он поставляет программное обеспечение правительственным учреждениям, чтобы они могли помочь ветеранам получать льготы от
Департамент по делам ветеранов США. Это чрезвычайно полезная работа, но это не прибыльная сфера. При минимальной марже мы должны использовать все доступные нам инструменты, чтобы делать больше с меньшим количеством разработчиков. И для этого функциональное программирование — как раз то, что нужно.

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

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

Одним из признаков того, что индустрия программного обеспечения готовится к смене парадигмы, является то, что функциональные возможности появляются во все большем количестве популярных языков. Отрасли потребуется гораздо больше работы, чтобы полностью осуществить переход, но преимущества этого очевидны, и, без сомнения, дело движется именно к этому.

Ли против Вейсмана | Энциклопедия Первой поправки

Дебора Вайсман и ее отец Дэниел разговаривают с интервьюером C-SPAN об их деле, оспаривающем конституционность публичной молитвы после окончания средней школы Деборы.

В решении Верховного суда Lee v. Weisman, 505 U.S. 577 (1992), незначительное большинство широко интерпретировало положение об учреждении Первой поправки, ограничивающее роль религии в государственных школах путем запрета молитв на школьных мероприятиях.

В 1989 году директор Роберт Э. Ли пригласил раввина Лесли Гаттермана произнести несектантскую молитву и благословение на выпускной церемонии средней школы в Провиденсе, Род-Айленд.

Вейсман утверждает, что школьная молитва представляет собой государственную поддержку религии

Дебора Вейсман была среди выпускников. Ее отец, Даниэль, безуспешно добивался временного запретительного судебного приказа, чтобы помешать раввину говорить, и Вейсманы присутствовали на церемонии. В благословении рабби Гуттерман сказал: «О Боже, мы благодарны Тебе за то, что ты наделил нас способностью к обучению. . . . Мы благодарим Тебя, Господь, за то, что ты сохранил нам жизнь, поддержал нас и позволил нам достичь этого особого, счастливого случая».

Затем Вейсман подал иск о постоянном судебном запрете, запрещающем местным школьным властям приглашать священнослужителей для чтения молитв на школьных церемониях.

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

Семья Вейсман беседует с репортерами за пределами Верховного суда в 1991 году. В их деле Ли против Вейсмана судья Энтони Кеннеди ввел тест на принуждение, заявив, что учащихся государственных школ принуждали участвовать в спонсируемых государством религиозных мероприятиях, когда государственные школы пригласил духовенство произнести призывы и благословения на таких мероприятиях, как выпускной. Третий слева — генеральный юрисконсульт Объединенного комитета баптистов Оливер «Базз» Томас, который подал заявление по этому делу. (Фотография перепечатана с разрешения Объединенного баптистского комитета.)

Кеннеди заявляет, что штату запрещено требовать «религиозного соответствия от студента»

После того, как суды низшей инстанции вынесли решение в пользу Вейсмана, округ подал апелляцию в Верховный суд США, где к нему присоединилась администрация Джорджа Буша-старшего в качестве amicus curiae. Там и округ, и администрация призвали суд использовать это дело для отмены трехсторонней проверки Лемона, которая контролировала дела об учреждении со времен Лемон против Курцмана (1971 г.).

В письме для суда судья Энтони М. Кеннеди заявил, что «в задачи правительства не входит составление официальных молитв для какой-либо группы американского народа, которые будут читаться в рамках религиозной программы, осуществляемой правительством, именно это и пытались сделать школьные чиновники».

Отмечая возможность психологического принуждения, Кеннеди заявил: «Конституция запрещает государству требовать религиозного подчинения от ученицы ценой посещения ее собственного выпускного в средней школе». Более того, суд отклонил приглашение повторно посетить Лемон, придя к выводу, что предыдущие школьные дела о молитвах послужили достаточным прецедентом для этого дела.

Решение удивило многих, которые думали, что Суд поддержит молитву под руководством школы

Несогласие судьи Антонина Скалии, к которому присоединились председатель Верховного суда Уильям Х. Ренквист, судья Байрон Р. Уайт и судья Кларенс Томас, высмеяло неприятие большинством истории и традиций в пользу «изменчивых философских пристрастий судей этого суда» и заклеймил тест на принуждение большинства «психологией, практикуемой дилетантами».

Многие наблюдатели были удивлены этим решением, полагая, что Суд Ренквиста воспользуется своим первым крупным делом о школьной молитве, чтобы отменить запрет на спонсируемую школой молитву и тест Лимона, и привнесет более приспособленческий взгляд в юриспруденцию Суда по пункту об учреждении.

Согласно документам судьи Гарри А. Блэкмана, суд был готов поддержать конституционность этой практики до тех пор, пока судья Кеннеди не пересмотрит свой голос.