LINUX.ORG.RU
ФорумTalks

антипаттерны в unix-утилитах

 , ,


1

5
sed 's/foo/FOO/w changed' test
sed -n 's/foo/FOO/p' test>changed

что такое sed с тз ООП? Правильно, это «божественный класс», он и сам с усами, может добавить строки в файл.

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

Однако же это не тот случай, тут чистый хардкор.

Предлагаю тут постить еще примеры демонстрирующие известный принцип дизайна unix «Каждая программа должна делать ровно одну вещь, и делать её хорошо», только наоборот, как в примере выше, инверсию, так сказать этого принципа. К слову, принцип этот, по-сути, совпадает с принципом разделения ответственностей в ООП, не?

Интересно, есть сейчас в юниксах и линуксах хоть что-то, что ему действительно соответствует?

Перемещено tailgunner из development



Последнее исправление: linearisation (всего исправлений: 2)
Ответ на: комментарий от evilface

Ты реально задолбал уже. Разговор идет о текстовых редакторах.

linearisation
() автор топика
Ответ на: комментарий от linearisation

…и как пользователи sed, мы хотим сделать своё обыденное дело: отредактировать файл. Для этого мы запускаем sed, сказав ему, что редактировать и как редактировать.

evilface ★★
()
Ответ на: комментарий от evilface

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

linearisation
() автор топика
Ответ на: комментарий от linearisation

А текст ему откуда брать? О работе с файлом ему придётся подумать в любом случае. Так что нет смысла усложнять жизнь и заставлять пользоваться перенаправлениями и левыми утилитами. Пойми уже, что редактирование текста в файле и открытие файла — две связанные между собой задачи.

wc по такой логике тоже не должен уметь работать с файлами, а только с потоками ввода-вывода?

evilface ★★
()
Ответ на: комментарий от evilface

а только с потоками ввода-вывода?

Которые, упс, тоже файлы и которым тоже надо делать read/write.

evilface ★★
()
Ответ на: комментарий от flyshoot

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

linearisation
() автор топика
Ответ на: комментарий от evilface

wc по такой логике тоже не должен уметь работать с файлами, а только с потоками ввода-вывода?

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

linearisation
() автор топика
Ответ на: комментарий от router

Это, конечно, факт, что systemd самая юниксвейная система инициализации, несмотря на то, что он далеко не система инициализации. Но проблема-то не в этом, а в том, что у ТС и понятие об юниксвейности своё собственное, отличное от других.

redgremlin ★★★★★
()
Ответ на: комментарий от flyshoot

«императивная парадигма» — это термин не вполне корректный, нет такой отдельной парадигмы. Понятие это противопоставляется декларативности, в том же контексте, как и разница между императивным и декларативным знанием («как» vs «что»). Поэтому, это вообще, как бы, не из той оперы. «императивность» не может иметь никакой четко определенной семантики и модели, это ортогональное понятие.

linearisation
() автор топика

Омг, какую только нечисть на лор с утра не заносит.

imul ★★★★★
()
Ответ на: комментарий от linearisation

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

flyshoot
()

А можно посмотреть на реализацию tail -f средствами перенаправления шелла?

infine
()
Ответ на: комментарий от flyshoot

Это уже обсуждалось выше. Да берет, он (в соответствии с интерфейсом), берет на себя обязанности записи на диск, причем, в соответствии со смыслом выражения, запись следует вместе с каждым изменением строки.

Представим себе, что мы открываем какой-то строчный редактор, типа ex

 ex file # открыли файл
 :3 # перешли к строке 3
 :s/foo/bar/ # заменили
 :5 # перешли к строке 5
 :s/foo/bar/w # заменили и ... what a fuck w???!!! Куда записали???!!! Ах да, это же мой диэтиламид d-лизергиновой кислоты работает
 w # записали
 q # вышли
 

linearisation
() автор топика

что такое sed с тз ООП

Твоя ошибка в том, что ты забыл, зачем ООПу правильное П. «Культ карго» в полный рост.

У многих юниксячих утилит функциональность несколько раздута - по той же причине, по которой в ОО считается «правильным» то, что ты тут проповедуешь, но с учётом того, что всё происходит в пользовательском шеле.

А выходит ли это за пределы «хорошо делать ровно одну вещь» - зависит от определения слова «вещь». Например, ф-я «<» могла появиться как побочный эффект внедрения ф-ии "-i", которую больше некуда было встраивать, а учитывая принятые в шеле методы композиции, это ещё и выглядело бы плохо, что в случае шела означает «плохую» реализацию => не соответствует Пути.

DonkeyHot ★★★★★
()

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

Avial ★★★★★
()

Спасибо, интересное наблюдение.

Присоединюсь

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

Как узнать размер исходных данных, сжатых gzip? Man gzip дает нам ответ на этот вопрос

zcat file.gz | wc -c

Антипаттер называется: Каждая программа должна делать ровно одну вещь, и делать её плохо.

Поясняю, с архитектурной точки зрения не подкопаться. zcat, pipe, wc. А вот с точки зрения производительности - ппц.

Deleted
()
Ответ на: комментарий от Deleted

Как узнать размер исходных данных, сжатых gzip? Man gzip дает нам ответ на этот вопрос ...
... с точки зрения производительности - ппц

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

а тут

Как узнать размер исходных данных, сжатых gzip? Man gzip дает нам ответ на этот вопрос

распаковать и посчитать (zcat file.gz | wc -c)

anTaRes ★★★★
()
Ответ на: комментарий от linearisation

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

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

Хотя, по-чесному, я приверженец СП....

Jetty ★★★★★
()
Последнее исправление: Jetty (всего исправлений: 1)
Ответ на: комментарий от anTaRes

Ой всё. Следующий шаг: «ман не место для документации» ?

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

займет больше чем чтение самого мана

Сколько у тебя времени заняло прочтение мана, что бы понять, что gzip абсолютный устаревший крап, не рекомендованный к применению?

Укажи они это в самом начале мана, не пришлось бы писать ни однострочников, ни сталкиваться с проблемами. А то люди, которым мало времени на чтение манов, продолжают использовать gzip по дефолту для чего угодно, а потом с этим приходится работать и разгребать legacy, которое размер исходных данных в контейнере вычисляет за время O(N). Отличное решение, когда сжатый контейнер имеет размер сотни гигабайт, браво.

Deleted
()

что такое sed с тз ООП?

Но, вообще, программа sed - это интерпретатор языка sed. Поэтому вопрос сводится к тому, почему программы python, perl (да что угодно, даже hugs), могут писать в файл, а не просто выполнять программу. Ведь твое исходное s/foo/FOO/w changed - это всего лишь текст программы на языке sed

Deleted
()
Ответ на: комментарий от Deleted

Укажи они это в самом начале мана

GZIP - хреновый архиватор

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

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

Поэтому воздержитесь от использования сего поделия.
 
С ув. разработчики.


так чтоль?

anTaRes ★★★★
()

Примечательно, что такие слова как «антипаттерн» привлекают определенных индивидуумов. Буду теперь знать, что это слово-детектор.

unt1tled ★★★★
()
Ответ на: комментарий от anTaRes

:) одна поправка - «хреновый компрессор»

Но, в случае, когда делают типа mysqldump | gzip > a.gz - это не особо важно, конечно

Deleted
()

антипаттерны в unix-утилитах

Ты паттерны то знаешь, чучело? =)

Siado ★★★★★
()

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

Делать всё, но плохо? Логично таки.

NextGenenration ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.