- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
if c = 'y' then
begin
Writeln('Yes');
end else
if c = 'n' then
begin
Writeln('No');
end;
Школоло / Говнокод #8617
0
Вот это кака... http://delphisources.ru/forum/showthread.php?t=19000
Запостил: 
Nikitiy_II,
(Updated )
в одной байте я могу разметить восемь таких хуйней
if, конечно, в данном случае прокатит, но что будет, когда проверок >=3, больше 10?
oh, shi
Для большей доходчивости: проверок >=3, или даже >10?
Если совсем по-русски: а если проверок будет больше трёх или даже больше десяти, так и будем if'ы лепить?
Или тогда не выводить результат нужно, а возвращать. Вдруг надо будет куда-нибудь его передать, сложить с другой строкой, отрендерить красиво?
Нормальные герои всегда идут в обход?
"Вдруг надо будет куда-нибудь его передать, сложить с другой строкой, отрендерить красиво?"
А чем вам begin-end/return внутри case не угодили?
Представлен код, по нему видно, чего хотел добиться автор. Есть иные варианты?
> А чем вам begin-end/return внутри case не угодили?
Вот и я про то же. Сначала добавить кейс на случай "мало ли чего", потом выделим пиксельный кусок в отдельную функцию по той же причине. А автор даже и не думал, что ему это может понадобиться.
Оверинжиниринг, вот что.
При двух вариантах большой разницы между ифом и кейсом нет. При 100 вариантах и кейс будет не в тему, давайте сразу на такой случай рассчитывать?
Хорошая привычка для программиста думать о том, что этот код придётся менять и поддерживать, но это понимаешь только побившись головой об стенку. If-else естественен для простых операций типа да/нет, а тут ещё возможны другие варианты: a-z. Это явно больше, чем да/нет.
"При 100 вариантах и кейс будет не в тему"
Как это не в тему?
А ведь есть ещё cancel, help="Я ничего не понял" и "Да пошли вы все нафиг".
selffix
?
Сомневаюсь.
Ну тогда баз второго if`а можно обойтись.
-- just for fun
expand :: Char -> Maybe String
expand = flip lookup [('y',"Yes"), ('n',"No")]
А нужны они, чтобы решать такие вот задачи.
Pandoc, Gitit, парсеры, математика (если есть биндинги)... Есть даже утилита типа socat (только базовый функционал) для 0MQ.
К тому же, его все равно нельзя назвать уникальным, есть же git/hg (и много проектов на github). Ограничения компиляторов на архитектуру (не под все есть) - тоже не в плюс портабельности.
Назвать, к примеру, Erlang не промышленным язык не поворачивается...
это переписывание данных из одного места в другое, с другого в третье итд
(с формы в переменные js, c переменных js переписать в xml, передать постом на страницу, из страницы передать в интерфес, из интерфейса данные xml переписать в сущность, из сущности скопировать в базу, из базы обратно переписать в сущность, потом скопировать в другую сущность, далее переписать из этой сущности в json итд),
В итоге выдача их (с необходимыми проверками доступа и валидности).
Люди, не изучайте ФЯП - от них баттхёрт
Именно!
Причем ООП зачастую еще усложняет и добавляет ненужные промежуточные стадии.
А чем больше в проекте абстракций, тем проще вводить новые, ненужные паттерны, которые снова просто копируют данные - всякие там декораторы, фасады итд..
Вот об этом всё ФП. Оно как бэ говорит нам "Да вы ебанулись все с этими объектами и новыми абстракциями". Тут главная идея: пиши простые маленькие независимые (желательно, чистые) функции, а язык позволит тебе комбинировать их бесчисленным количеством способов.
Взять, к примеру, шаблонизаторы для html. В Java желательно использовать jsp, а чтобы комбинировать view нужно прикручивать Tiles/переходить на jsf с facelets.
В Lisp тебе достаточно написать десяток макросов (страница кода) для удобных генерации и вывода тегов в поток, и вуаля, у тебя есть язык шаблонов. Который на самом деле - обычный Lisp, со всеми вытекающими.
View - это функция, принимающая на вход таблицу параметров (и, быть может, поток). Хочешь композитный view - напиши простую функцию, принимающую на вход помимо таблицы параметров ещё и таблицу функций, отрисовывающих отдельные области.
В результате - никаких лишних абстракций, обошлись функциями + микро DSL для отрисовки html-тегов.
Почему не стоит?
Не всегда. Если вынести работу с рефлексией в библиотечный класс с удобными обертками.
>рефлективные вызовы методов гораздо медленнее обычных
Груви медленей жавы в 100 раз (вполне возможно и из-за рефлексии), скала в 5 раз.
Короче спорное утверждение.
Злоупотреблять однозначно не следует.
invokedynamic нас всех спасёт, если не успеет утянуть на дно бремя обратной совместимости.
> скала в 5 раз
"спорное утверждение"
http://shootout.alioth.debian.org/u32/scala.php
Памяти обычно больше требует, это да.
Насколько я знаю тулзы для работы с бинами больше используют не рефлексию, а интроспекцию - она быстрее (возможно потому что где-то в недрах явы хитро кешируется).
Однако в конечном счёте всё равно придётся делать тормозной Method.invoke().
+100500
Писал на няшной сишечки и батхерта не ведовал. Но только стоило... Ну ты понел.
Именно поэтому я за «PHP».
я эксперт в этом деле
Меня тоже от них тошнит. Достала эта императивщена.
Плюсую пост.
Фууу. Турнирный оператор.