Ответ прост: потому что билет на это место мог бы купить кто-то другой и досидеть до конца.
При этом при такой схеме возникает тысяча ньюансов, например, очень легко саботировать просмотры у «конкурирующего» кинотеатра — приходим толпой по 50 человек, сидим первые 5 минут, встаем и уходим. В итоге ползала (или даже весь?) остается пустым и кинотеатр получает 500 рублей. И так много-много раз.
Да я сам счастливый обладатель PS3, поэтому против консольной графики плохого ничего не могу сказать. Однако самые свежайшие графические плюшки (тесселяция и проч.) DX11/OpenGL4.x ими не поддержаны, соответственно в портах на консоли их все равно не будет. Именно в этом плане на рынке они не особо востребованы. Поэтому так и говорю.
Да о чем речь, некоторым PS3 играм даже AA толкового недостаёт (не знаю как на XBox с этим дела обстоят).
С другой стороны Source славен тем, что шустр, и «бегает» достаточно резво даже на слабеньких машинах, это тоже плюс я считаю.
В общем суть моего комментария в том, что нельзя списывать сурс со счетов только из-за его графической составляющей. :)
Не знаю кого как, но меня лично немного коробит от изречений вроде «я узнал Source по угловатым моделям». Source — это в первую очередь игровой движок, он содержит множество различных составляющих (физика, анимация, звук и, конечно же, графика). Я уже не первый раз вижу, как «непродвинутось» (назовём это так) его графической составляющей воспринимается как камень в огород всего движка, мол, он морально устарел и т.д. и т.п.
Добавить в графическую составляющую движка поддержку различных наворотов DirectX 11/OpenGL 4.x на мой взгляд особого труда не составит, но рынку (взгляните хотя бы на консоли 2005/2006 годов выпуска) пока это не особо надо, пусть CryTek гоняются за «красивостями».
Почему-то автор забыл про языки, в которых indentation это не просто способ оформления кода, это часть стандарта языка. Помимо упоминавшегося уже здесь Python хочу напомнить о существовании Haskell, в котором «форматирование» табами надолго может затянуть в поиск ошибки, которой не видно на глаз.
Лично я за пробелы. Хотя бы просто потому, что величина отступа, на мой взгляд, наименьшая из проблем с переходом на новый «стандарт» форматирования, с которой может столкнуться программист в новом коллективе. Например, для Java различия между
public class Foo {
public void foo() {
return 0;
}
}
и
public class Foo
{
public void foo()
{
return 0;
}
}
для меня куда большая проблема с читабельностью, чем эти ваши табы.
Не знаю, меня очень заинтересовал. Я ушел с андройда (Acer Liquid) на Е71, очень доволен аппаратом, но я смирился с тем, что эта платформа «мертвая». Поэтому был очень удивлен продолжению традиций qwerty смартфонов Е-серии. Думаю, что немного подожду снижения цен и поменяю Е71 на Е6.
Здесь можно двояко трактовать. Зачастую сталкиваешься с менеджерами со стороны заказчиков, которые не могут сформулировать точное и строгое ТЗ, они просто не понимают чего нам еще не понятно. Но это клиент, увы, с ним приходится работать и приходится вытрясать эти требования, иначе же в любом случае тебе всё переделывать…
Разве это готовый код, который можно скомпилировать и запустить, и в котором можно «пообщаться с собой»? Где реализация SendRequest? Что такое Unit? При этом Вы пишете в консоль прямо в коде, описывающем протокол взаимодействия.
Увы, но на мой взгляд это демонстрация минусов императивных языков, Вы не моргнув и глазом намешали описание взаимодействия и тонкости конкретной реализации.
Признаться честно, мне было сложно проследить нить рассуждений автора. Сложно было отделить… скажем так API от тонкостей реализации в тексте. То есть сложно было вычленить ту часть кода, которая мне нужна, чтобы вот взять и начать использовать эту монаду на практике.
Позволю себе несколько ремарок:
1) Статус определённой вначале функции test (я бы назвал ее лучше example) для меня был темным до тех пор, пока я не увидел листинг диалога с интерпретатором в конце статьи. Итак: Функция тест является описанием протокола взаимодействия с неким собеседником. Замечу, что нам не интересно кто это будет и какого будет его состояние, мы просто описываем последовательность отправок и приёма сообщений (а также, возможно, некоторого промежуточного ввода\вывода, допустим обращения к базе, что реализуется через вызов функции io). Именно такое описание взаимодействий есть цель, к которой стремится автор в течение всей статьи.
2) «Дабы не отвлекаться на лишние детали и не иметь необходимости запускать несколько программ, я упрощу задачу для статьи». На мой взгляд всё лишь усложнилось, потому что перестало быть видно «отдельных участников» обмена сообщениями. Лично для меня это было понять тяжелее всего. Но пока по отложим этот вопрос.
3) Итак, функции send и response. Когда я впервые увидел эти функции при первом беглом чтении статьи, я решил, что это и есть ОНО — отделение посылки сообщения и ответа на него, ан нет. На самом деле функцию send стоило бы назвать sendAndRecieve, ибо она описывает не только ЧТО отправить, но и КАК обработать полученный в ответ результат. А функцию response (ответ) в свою очередь лично я бы назвал request (запрос), ибо это более точно отражает, на мой взгляд, суть процесса.
4) Наконец, run — это инициация диалога act (да, того самого, который представлен, например, функцией test) с собеседником, заданным состоянием a.
5) И последнее — в данном примере мы ведём диалог сами с собой (trace и listener помогают нам в этом)! Может быть это тривиальная мысль, но я никак не мог ее уловить, смотрим: сперва мы инициализируем два диалога с самим собой, причем наш ввод выступает как раз тем самым «собеседником», с которым мы общаемся посредством протокола test. В первый раз нам прислали 10, во второй — 20. По каким-то одним нам ведомым причинам в ответ мы отправляем, соответсвенно, 11 и 21 (это и будут первые слагаемые нашей результирующей суммы). Они возводятся в квадрат нашим протоколом и вновь обратно к нам. Теперь мы добавляем более безумные 444 и 122, в результате дающие нам суммы 465 и 133.
Вывод: я заключил для себя следующее. Функции, описывающие протокол (типа test) взаимодействия, я бы назвал «серверной частью» (для простоты восприятия). Конкретный же «клиент» отправляет «запросы» к этому протоколу откуда-то извне (легко переписать это дело на сокеты) — в нашем случае это была строка интерпретатора и функция f (которую опять же следовало бы назвать как-то более осмысленно).
При этом при такой схеме возникает тысяча ньюансов, например, очень легко саботировать просмотры у «конкурирующего» кинотеатра — приходим толпой по 50 человек, сидим первые 5 минут, встаем и уходим. В итоге ползала (или даже весь?) остается пустым и кинотеатр получает 500 рублей. И так много-много раз.
Бредовая идея.
Да о чем речь, некоторым PS3 играм даже AA толкового недостаёт (не знаю как на XBox с этим дела обстоят).
С другой стороны Source славен тем, что шустр, и «бегает» достаточно резво даже на слабеньких машинах, это тоже плюс я считаю.
В общем суть моего комментария в том, что нельзя списывать сурс со счетов только из-за его графической составляющей. :)
Добавить в графическую составляющую движка поддержку различных наворотов DirectX 11/OpenGL 4.x на мой взгляд особого труда не составит, но рынку (взгляните хотя бы на консоли 2005/2006 годов выпуска) пока это не особо надо, пусть CryTek гоняются за «красивостями».
Лично я за пробелы. Хотя бы просто потому, что величина отступа, на мой взгляд, наименьшая из проблем с переходом на новый «стандарт» форматирования, с которой может столкнуться программист в новом коллективе. Например, для Java различия между
и
для меня куда большая проблема с читабельностью, чем эти ваши табы.
ИМХО, как-то нечитабельно…
LTS релизы выходят каждые два года, соответственно следующий LTS — 12.04.
Увы, но на мой взгляд это демонстрация минусов императивных языков, Вы не моргнув и глазом намешали описание взаимодействия и тонкости конкретной реализации.
4) Конечно же, а — это не состояние собеседника, а скорее состояние «сервера» перед диалогом по «протоколу» act.
Признаться честно, мне было сложно проследить нить рассуждений автора. Сложно было отделить… скажем так API от тонкостей реализации в тексте. То есть сложно было вычленить ту часть кода, которая мне нужна, чтобы вот взять и начать использовать эту монаду на практике.
Позволю себе несколько ремарок:
1) Статус определённой вначале функции test (я бы назвал ее лучше example) для меня был темным до тех пор, пока я не увидел листинг диалога с интерпретатором в конце статьи. Итак:
Функция тест является описанием протокола взаимодействия с неким собеседником. Замечу, что нам не интересно кто это будет и какого будет его состояние, мы просто описываем последовательность отправок и приёма сообщений (а также, возможно, некоторого промежуточного ввода\вывода, допустим обращения к базе, что реализуется через вызов функции io). Именно такое описание взаимодействий есть цель, к которой стремится автор в течение всей статьи.
2) «Дабы не отвлекаться на лишние детали и не иметь необходимости запускать несколько программ, я упрощу задачу для статьи». На мой взгляд всё лишь усложнилось, потому что перестало быть видно «отдельных участников» обмена сообщениями. Лично для меня это было понять тяжелее всего. Но пока по отложим этот вопрос.
3) Итак, функции send и response. Когда я впервые увидел эти функции при первом беглом чтении статьи, я решил, что это и есть ОНО — отделение посылки сообщения и ответа на него, ан нет. На самом деле функцию send стоило бы назвать sendAndRecieve, ибо она описывает не только ЧТО отправить, но и КАК обработать полученный в ответ результат. А функцию response (ответ) в свою очередь лично я бы назвал request (запрос), ибо это более точно отражает, на мой взгляд, суть процесса.
4) Наконец, run — это инициация диалога act (да, того самого, который представлен, например, функцией test) с собеседником, заданным состоянием a.
5) И последнее — в данном примере мы ведём диалог сами с собой (trace и listener помогают нам в этом)! Может быть это тривиальная мысль, но я никак не мог ее уловить, смотрим: сперва мы инициализируем два диалога с самим собой, причем наш ввод выступает как раз тем самым «собеседником», с которым мы общаемся посредством протокола test. В первый раз нам прислали 10, во второй — 20. По каким-то одним нам ведомым причинам в ответ мы отправляем, соответсвенно, 11 и 21 (это и будут первые слагаемые нашей результирующей суммы). Они возводятся в квадрат нашим протоколом и вновь обратно к нам. Теперь мы добавляем более безумные 444 и 122, в результате дающие нам суммы 465 и 133.
Вывод: я заключил для себя следующее. Функции, описывающие протокол (типа test) взаимодействия, я бы назвал «серверной частью» (для простоты восприятия). Конкретный же «клиент» отправляет «запросы» к этому протоколу откуда-то извне (легко переписать это дело на сокеты) — в нашем случае это была строка интерпретатора и функция f (которую опять же следовало бы назвать как-то более осмысленно).
[пропущена после восьмого символа (перед вторым>)1)
import Data.List
main = mapM_ (putStrLn . foo) [1..6]
foo n = concat $ intersperse "-" $ (if odd n then id else reverse) $ take n $ map show [1..]
2) (Я сильно вспотел, когда писал это)
codepad.org/NQUSqcjc