Философия Unix впадает в немилость в сообществе Ruby? [закрытый]
6 ответов
Философия конвейеров и простых инструментов Unix предназначена для текста . Он по-прежнему актуален, но, возможно, не так актуален, как раньше:
Мы видим все больше инструментов, вывод которых не предназначен для легкого анализа другими программами.
Мы видим гораздо больше XML там, где есть нет особого преимущества для передачи текста через фильтры и там, где регулярные выражения являются рискованной игрой.
Мы наблюдаем большую интерактивность , тогда как в Unix конвейеры информация течет только в одном направлении.
Но хотя мир немного изменился, я все еще согласен с критикой Корна. Определенно плохой дизайн для создания больших монолитных программ, которые не могут взаимодействовать с другими программами, независимо от языка. Правила такие же, как и всегда:
Помните, что выходные данные вашей собственной программы могут быть входными данными другой программы.
Если ваша программа имеет дело с одним типом данных (например, производительность кода, отправленного студентами, что я делал на прошлой неделе) убедитесь, что для ввода и вывода этих данных используется один и тот же формат.
Для взаимодействия с существующими инструментами Unix ввод и вывод должны быть ASCII и строчно-ориентированными. Многие Интернет-протоколы IETF (SMTP, NNTP, HTTP) являются отличными примерами.
Вместо написания большой программы подумайте о написании нескольких небольших программ, связанных с существующими программами конвейерами оболочки. Например, некоторое время назад в блоге xkcd был ужасный конвейер для поиска анаграмм в
/ usr / share / dict / words.Постепенно переходите к сценариям оболочки, делая вашу интерактивную оболочку такой, с которой вы также можете создавать сценарии. (Я использую
ksh, но любая POSIX-совместимая оболочка является разумным выбором.)
В заключение есть действительно два очень важных способа повторного использования кода :
Написание небольших программ которые хорошо сочетаются друг с другом при соединении конвейерами оболочки (Unix).
Напишите небольшие библиотеки, которые хорошо сочетаются друг с другом при соединении с помощью
import,#include,load,требуютилииспользуют(Ruby, C ++ STL, интерфейсы и реализации C и многие другие).
В первой парадигме структура зависимостей - это простой (всегда линейный) и, следовательно, легкий для понимания, но вы более ограничены в том, что вы можете выразить. Во второй парадигме ваша структура зависимостей может быть любым ациклическим графом - гораздо больше выразительной силы, но она включает в себя способность создавать беспричинную сложность.
Обе парадигмы по-прежнему актуальны и важны; для любого конкретного проекта, какой из них вы выберете, больше связан с вашими клиентами и отправной точкой, чем с какими-либо внутренними достоинствами парадигмы. И, конечно же, они не исключают друг друга!
Я думаю, что философия Unix начала терять популярность с созданием Emacs.
Я думаю, довольно простое объяснение состоит в том, что инструменты Unix доступны только в Unix. Однако подавляющее большинство пользователей используют Windows.
Я помню, как в последний раз я пытался установить Nokogiri, это не удалось, потому что не удалось запустить uname -p . Для этого не было абсолютно никаких веских причин. Вся информация, которую можно получить, запустив uname -p , также доступна из Ruby. Кроме того, uname -p на самом деле даже не Unix, это нестандартное расширение GNU, которое даже не гарантирует работу в Unix и, например, полностью не работает в некоторых дистрибутивах Linux.
Итак. , вы можете использовать Unix и потерять 90% пользователей,
Похоже, что он не полностью утерян. Я прочитал недавнюю запись в блоге Райана Томайко , которая расширила философию UNIX и то, как она поддерживается HTTP-сервером Unicorn . Однако у него было такое же общее чувство, что сообщество рубинов игнорирует философию UNIX в целом.
Мой голос - да. Субъективный, но отличный вопрос программирования.
Просто личный анекдот в то время, когда мы переписывали программу массового вывода на печать для страховых компаний. Нас буквально ругали советники за «программирование» в оболочке. Мы осознали, что он был слишком разрозненным, а языки были слишком разрозненными, чтобы быть полным.
Может быть.
Внезапно мультипроцессор Intel boxen стал обычным явлением, а fork () действительно не работал так ужасно, как все всегда предупреждался о новой эпохе приложений (вспомните дни VB). Программы массовой печати (которые запрашивали базу данных, преобразовывались в вывод troff , а затем в PostScript через msgsnd и затем отправлялись в очередь LPD сотнями тысяч) отлично масштабируется по всем системам и не
Я с мистером Корном, но это не вина Perl, это программисты Perl решают, что Perl достаточно. В многопроцессорных системах, может быть, этого и достаточно.
Я надеюсь, что разработчики Ruby, Perl, Python и (ах!) Даже Java-разработчики сохранят свое преимущество в конвейере оболочки. Философия разработки имеет неотъемлемую ценность для неявного масштабирования и взаимодействия, разделения обязанностей и модульного дизайна.
При правильном подходе, с нашими модулями обработки с массивным ядром на горизонте, философия Unix может снова получить популярность.
Нет. Unix и Ruby живы и здоровы
Unix и Ruby живы и здоровы, акции производителя Unix компании Apple выведены на орбиту, у linux есть безотзывные выкопанные позиции, на которых работают серверы, системы разработки и лаборатории, а империя настольного программного обеспечения Microsoft окружена мощными SaaS варварами, такими как Google и армия союзников.
У Unix никогда не было более светлого будущего, и Ruby является одним из его ключевых союзников.
Я не уверен, что шаблон программного обеспечения в любом случае является таким ключевым элементом Unix. Это было потрясающе в свое время, учитывая общее неуклюжее качество конкурирующих CLI-инструментов, но Unix ввел много других вещей, включая элегантный процесс и модель ввода-вывода.
Также, я думаю, вы обнаружите, что многие из этих программ Ruby используют различные интерфейсы Unix и софт-инструментов изнутри. Проверьте popen() и различные методы Process
Я думаю, что Ruby просто имеет свою собственную сферу влияния.
.