vit_r: default (vit_r)
[personal profile] vit_r
Гуры, проповедующие, что язык программирования тем более велик, чем больше сложных преобразований можно в нём впихнуть в одну строчку, напоминают мне тех заказчиков, которые требуют, чтобы единственным элементом управления программы была кнопка «Start».

Date: 2013-05-02 01:34 pm (UTC)
From: [identity profile] orleanz.livejournal.com
Если строчка красивая и понятная, почему не впихнуть

примеры

(1 to 10) map { _ * 2 }

еще

val fileLines = io.Source.fromFile("data.txt").getLines.toList

еще

val (passed, failed) = List(49, 58, 76, 82, 88, 90) partition ( _ > 60 )

еще
(кстати, тут параллельная обработка)

val result = dataList.par.map(line => processItem(line))

Date: 2013-05-02 01:39 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Если строчка красивая и понятная, почему не впихнуть

Можно. Если пишешь книжку по красивые языки программирования.

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

Date: 2013-05-02 01:43 pm (UTC)
From: [identity profile] orleanz.livejournal.com
да где же в примерах выше сложность?

Date: 2013-05-02 02:34 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Она не может быть в тексте. Сложность определяется взаимодействием текста с тем, кто читает. Причём, в контексте.

Date: 2013-05-02 10:27 pm (UTC)
From: [identity profile] qehgt.livejournal.com
Она не сложнее, она проще.

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

Date: 2013-05-02 10:34 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Кнопка "старт" она тоже проще. Если смотреть со стороны кнопки, а не того, что под ней.

Date: 2013-05-02 10:53 pm (UTC)
From: [identity profile] qehgt.livejournal.com
Именно. Код тогда становится кратким, когда оперирует терминами предметной области (или близок к ним). Проще уже некуда - упираемся в сложность задачи.

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

Date: 2013-05-02 10:58 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Код не становится, не оперирует, вообще не одушевлён и не имеет божественной сущности.

Примеры выше в реальном проекте будут бредом. Надеюсь, не надо объяснять, если у нас проблема в умножении элементов массива на два, значит какие-то траблы с пониманием задачи.

Date: 2013-05-02 11:28 pm (UTC)
From: [identity profile] qehgt.livejournal.com
Мне кажется, мы говорим о чём-то разном.

Date: 2013-05-02 01:46 pm (UTC)
From: [identity profile] metaclass.livejournal.com
Не сложных, а теоретически обоснованных. Чтобы быть уверенным что строчка делает именно то, что от нее ожидается.

Ну и что-то вроде (select [a b c] :from table :where predicate ) или (map (juxt :a :b :c) (filter predicate table)) выглядит гораздо лучше и понятнее чем то же самое, разложенное на десяток строк и анонимных классов.

Date: 2013-05-02 02:30 pm (UTC)
From: [identity profile] sab123.livejournal.com
Такие строчки имеют свойство делать не то, что от них ожидается. Ну и читать их тяжело, да.

Date: 2013-05-02 02:38 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Самое фиговое в них искать ошибки. Особенно когда, да, делают они не то, что должны.

Date: 2013-05-02 02:54 pm (UTC)
From: [identity profile] sab123.livejournal.com
Кстати, SQL имеет похожее свойство, когда выходит за рамки простых запросов. С другой стороны, регулярные выражения тоже не отличаются простотой, но я их люблю.

Date: 2013-05-02 03:18 pm (UTC)
From: [identity profile] vit-r.livejournal.com
У регулярных выражений нет побочных эффектов и только два результата "нашли - не нашли". Плюс их нужно подробно комментировать.

SQL - это уже магия. Оптимизацию надо проверять на реальных данных.

Date: 2013-05-02 04:04 pm (UTC)
From: [identity profile] sab123.livejournal.com
У регулярных выражений есть найденные подвыражения в скобках. Ну и это, в классическом формате (не новом перловом) там не очень-то покомментируешь.

SQL способен выдавать сюрпризы просто в содержимом данных, безотносительно оптимизации.

Общий принцип тут наверное такой: пока выражение в хитром синтаксе делает что-то простое и одноуровневое, оно действительно коротко, понятно и полезно. Хоть регулярное выражение, хоть SQL, хоть продемонстрированный тут людьми map (кстати, в питоне такое называют comprehensions). А когда оно начинает навроачиваться слоями на слои, то делается непонятным, кривым и вредным.

В этом смысле интересен г-гловый стандарт кодописания на питоне: одноуровневые компрехенсии разрешаются и поощряются, многоуровневые - запрещаются. И он, наверное, разумный.

Date: 2013-05-02 02:38 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Не сложных, а теоретически обоснованных.

Ну-ну. Много я повидал у программистов так называемых "теоретических обоснований".

То, что выглядит лучше и понятнее, да. При определённых условиях. Но пост только про то, что краткость не всегда сестра таланта.

Date: 2013-05-02 02:10 pm (UTC)
From: [identity profile] mstone.livejournal.com
Гуры have a point. Количество впихуемых в одну строчку сложных преобразований коррелирует (http://xkcd.com/552/) с наличием в языке а) мощного механизма абстракций б) лаконичного, "визуального" синтаксиса. А дальше как с любым мощным оружием: можно использовать во зло (по глупости, обычно (http://en.wikipedia.org/wiki/Hanlon's_razor)), можно во благо.

Date: 2013-05-02 02:41 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Программирование - это не стрельба по мишеням. Мощное оружие нужно далеко не всегда.

В этом ракурсе наиболее мощный словарь был у Эллочки-Людоедки.

Date: 2013-05-02 02:44 pm (UTC)
From: [identity profile] vanderdecken-lj.livejournal.com
Когда читаешь книжку Страуструпа о С++, постоянно натыкаешься на рассуждения о неоднозначности, "ошибкоемкости", умолчаниях. Т.е. любую конструкцию он рассматривает через призму потенциального порождения логических ошибок в программе.

Date: 2013-05-02 03:22 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Это практически у всех, имеющих большой практический опыт работы в индустрии. Две бессонных ночи посидишь перед релизами, в следующий раз будешь смотреть на надёжность.

Date: 2013-05-03 12:25 pm (UTC)
From: [identity profile] zorag-ringael.livejournal.com
Интересно, что большая часть комментаторов рассматривает проблему сквозь призму языка используемого в данный момент.

А мне почему-то сразу вспомнился Пёрл и разные чудесные конструкции на нем.
Типа

`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`

ps: Кстати, некоторые гайдлайны по Яве не рекомендуют использование даже тернаного оператора ? (который еще из С пришел).
if-конструкции, конечно, занимают несколько строк, но более читаемы.

Date: 2013-05-03 12:47 pm (UTC)
From: [identity profile] vit-r.livejournal.com
Перл создавался с идеей сделать язык столь же гибкий как и естественный. Понятно, что на нём можно извращаться гораздо больше, чем в более строгих.

Гайдлайны всем хороши, но правила там придумывают по методу "мне нравится" или "мы в школе проходили". Так что полезные вещи от мусора совершенно не отделены.

If конструкции не то, чтобы более читаемы, просто более надёжны. Впрочем, программистов, не освоивших ?: тоже видел.

Date: 2013-05-05 11:17 am (UTC)
From: [identity profile] perepertoz.livejournal.com
то есть всякие STEPS (http://ailev.livejournal.com/960827.html) занимаются фигнёй ?

Date: 2013-05-05 11:46 am (UTC)
From: [identity profile] vit-r.livejournal.com
1. Краткость в данном случае не сестра таланта. (Я имею ввиду вопрос). Стоит хотя бы писать, из чего следуют выводы. Хотя, конечно, из вежливости стоит дать ещё и контекст.

2. В данной редакции вопрос звучит "Ты, гнида, против коммунистов?" На такое ответ всегда "Да". Просто, чтобы не расстраивать спрашивающего.

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

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

5. Сама идея в том, что сокращение текста сокращает объём информации - порочна.

Profile

vit_r: default (Default)
vit_r

February 2026

S M T W T F S
12 34 567
8 9 1011121314
15161718192021
22232425262728

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Feb. 12th, 2026 09:38 am
Powered by Dreamwidth Studios