Комментарии 37
Где мы свернули не туда?
+28
В тот момент, когда люди вместо того что бы чинить старое, создают новое.
+12
Не просто создают новое, а объявляют старое безнадежным и ожидают, что новое само собой будет лучше. Вместо старых проблем получают новые, плюс в новом коде непременно будут новые (свежие, если вам так приятнее) ошибки, какое-то время правят, потом «новое» опять объявляют безнадежным, процесс продолжается бесконечно.
+3
Наверное когда ученик из этого коана стал учителем.
При том что коан изначально очень мудрый. Но описанное в посте — это просто рекурсия этого коана. Учителя — ученики учеников этого ученика.
Мастер Фу и десять тысяч строк
Однажды Мастер Фу сказал заезжему программисту: «В одной строке кода shell-сценария больше духа UNIX, чем в десяти тысячах строк кода на С!»
Программист, гордый своими познаниями в С, ответил: «Может ли быть такое? Ведь С — язык, в котором реализовано само ядро UNIX!»
На это Мастер Фу ответил: «Это так. Тем не менее, в одной строке shell-сценария больше духа UNIX, чем в десяти тысячах строк С!»
Программист выглядел удрученным. «Но ведь через язык С мы познаем просвещенность патриарха Ритчи! Мы уподобляемся человеку с операционной системой и компьютером, который получает непревзойденную производительность!»
Мастер Фу сказал: «То, что ты говоришь, правда. Однако в одной строке shell-сценария больше духа UNIX, чем в десяти тысячах строк С».
Программист усмехнулся и поднялся, чтобы удалиться. Но Мастер Фу кивнул своему ученику Ньюби, который писал строку shell-кода на стоящей рядом белой доске, и сказал: «Господин программист, посмотрите на этот конвейер! Не заняла бы его реализация на C десять тысяч строк?»
Просматривая то, что писал Ньюби, программист что-то бормотал в бороду. В конце концов, он согласился, что это так.
«И сколько часов потребовалось бы вам для реализации и отладки этой программы на языке С?»
«Много», — признал заезжий программист. «Но только безумец стал бы тратить столько времени, когда его ждет множество более достойных задач».
«Так кто лучше понимает дух UNIX?» — спросил Мастер Фу. «тот, кто пишет десять тысяч строк, или тот, кто, сознавая тщетность этих усилий, извлекает пользу, не программируя?»
Услышав это, программист достиг просветления.
Программист, гордый своими познаниями в С, ответил: «Может ли быть такое? Ведь С — язык, в котором реализовано само ядро UNIX!»
На это Мастер Фу ответил: «Это так. Тем не менее, в одной строке shell-сценария больше духа UNIX, чем в десяти тысячах строк С!»
Программист выглядел удрученным. «Но ведь через язык С мы познаем просвещенность патриарха Ритчи! Мы уподобляемся человеку с операционной системой и компьютером, который получает непревзойденную производительность!»
Мастер Фу сказал: «То, что ты говоришь, правда. Однако в одной строке shell-сценария больше духа UNIX, чем в десяти тысячах строк С».
Программист усмехнулся и поднялся, чтобы удалиться. Но Мастер Фу кивнул своему ученику Ньюби, который писал строку shell-кода на стоящей рядом белой доске, и сказал: «Господин программист, посмотрите на этот конвейер! Не заняла бы его реализация на C десять тысяч строк?»
Просматривая то, что писал Ньюби, программист что-то бормотал в бороду. В конце концов, он согласился, что это так.
«И сколько часов потребовалось бы вам для реализации и отладки этой программы на языке С?»
«Много», — признал заезжий программист. «Но только безумец стал бы тратить столько времени, когда его ждет множество более достойных задач».
«Так кто лучше понимает дух UNIX?» — спросил Мастер Фу. «тот, кто пишет десять тысяч строк, или тот, кто, сознавая тщетность этих усилий, извлекает пользу, не программируя?»
Услышав это, программист достиг просветления.
При том что коан изначально очень мудрый. Но описанное в посте — это просто рекурсия этого коана. Учителя — ученики учеников этого ученика.
+2
Это все Тьюринг виноват
+6
Webscale же!
+1
Подмена понятий. Можно написать аналогичный текст на тему «зачем мне IDE, гит, скрам, багтрекер, юнит-тесты, приемочные тесты, дженкинс, автоматический деплоймент, если я хочу написать hello world для лабораторки в универе».
Надеюсь, все понимают жизненную необходимость всего вышеперечисленного для больших проектов. А теперь попытайтесь это объяснить человеку, который писал лабораторки на паскале.
С распределенными отказоустойчивыми системами всё то же самое.
Надеюсь, все понимают жизненную необходимость всего вышеперечисленного для больших проектов. А теперь попытайтесь это объяснить человеку, который писал лабораторки на паскале.
С распределенными отказоустойчивыми системами всё то же самое.
+19
Насколько увидел я, тут высмеивается использование over9000 технологий как раз таки для «лабораторки в универе».
+24
А напишите про IDE, раз можно, а то от vim отвыкнуть не могу (даже для небольших java коннекторов к разным API).
А пост классный, я для себя много почерпнул и увидел как все это связывается во едино.
А пост классный, я для себя много почерпнул и увидел как все это связывается во едино.
0
А что про IDE? IDE — это качественный автокомплит, линтер, навигация по исходникам и документации. Если вы хорошо знаете все нужные вам API и используете скриптовый язык (или автоматическую рекомпиляцию), то IDE не так уж и нужно. Но лично я слишком быстро меняю библиотеки и технологии, чтобы заучивать их наизусть.
Насчет технических подробостей в этом посте — отнеситесь аккуратно, там есть неточности.
Насчет технических подробостей в этом посте — отнеситесь аккуратно, там есть неточности.
+2
Вы немного лукавите. Если вы всерьёз используете vim, то у вас там к нему прилагается тонна собственноручно изготовленных или подобранных конфигов и скриптов, которые обеспечивают нормальную работу. Подсветку, автокомплит, рефакторинг, вот это вот всё.
Т.е. вы по сути написали собственную IDE, взяв vim в качестве основы. Ну, а кому-то не хочется тратить время на написание IDE, и он берёт уже готовую.
Т.е. вы по сути написали собственную IDE, взяв vim в качестве основы. Ну, а кому-то не хочется тратить время на написание IDE, и он берёт уже готовую.
0
Вы плохо себе представляете работу в Vim.
Чем больше вы познаете его, тем больше плагинов вы начинаете удалять.
Чем больше вы познаете его, тем больше плагинов вы начинаете удалять.
0
Вот кстати несогласен :)
0
Да, все так. Недавно поймал себя на этой мысли.
Однко же, удивительно встретить холивар vim/IDE в посте про докер.
Однко же, удивительно встретить холивар vim/IDE в посте про докер.
+1
It’s San Francisco. Everyone’s into distributed systems and BDSM.
Это из Сан-Франциско. Все, кто относятся к распределенным системам. BDSM.
facepalm.jpg
Перевод стоило бы вычитать перед публикацией. Две глобальные проблемы — повсеместная калька в порядке слов («Kubernetes кластер», «RestAPI слой») и то, что названия технологий то в оригинале, то транслитерированы на русский и склоняются. Нужно определиться.
+8
Две глобальные проблемы — повсеместная калька в порядке слов («Kubernetes кластер», «RestAPI слой»)Кубернетовый кластер и рестапишный слой, нет?
+1
Прямой порядок слов подошел бы лучше, но и так тоже можно, если выдержать всю статью в едином стиле.
+1
А вам не кажется, что «кластер Kubernetes» и «слой RestAPI» звучит как-то более… приятно для русскоязычного уха?
У меня есть своя теория заговора. Мне кажется, что Русский Язык пытаются захватить страшные люди с другой планеты, которые везде на вывесках пишут что-то типа «Эверест консалтинговая компания» и «33 Зуба стоматология».
У меня есть своя теория заговора. Мне кажется, что Русский Язык пытаются захватить страшные люди с другой планеты, которые везде на вывесках пишут что-то типа «Эверест консалтинговая компания» и «33 Зуба стоматология».
+4
А вам не кажется, что «кластер Kubernetes» и «слой RestAPI» звучит как-то более… приятно для русскоязычного уха?Приятнее, но смысл не совсем совпадает. Лексически «кластер Kubernetes» ≈ кластер, составленный из Kubernetes'ов, тогда как Kubernetes-кластер («кубернетовый») — кластер, управляемый (или как оно там организовано?) Kubernetes'ом. Так же и «слой RestAPI» ≈ «слой всяких RestAPI», а «RestAPI-слой» — это слой, [отвечающий за / предоставляющий] RestAPI.
+3
Во-первых, вы написали «Kubernetes-кластер» (через дефис), что уже значительно грамотнее. Во-вторых, никто не мешает написать «кластер типа Kubernetes» или «Kubernetes-управляемый кластер». Просто в оригинальном тексте было много игры слов, основанной на терминах и их альтернативном прочтении, поэтому, видимо, переводилось для «людей, которые знают английский, но которым лень читать по-английски всё».
Есть такая категория переводчиков, которые стремятся писать по-английски, но русскими словами и пунктуацией. Некоторые даже утверждают, что так «правильно» переводить художественные тексты. Правда как всегда где-то посередине. В любом случае, для того, чтобы ХОРОШО перевести текст, его придется спера ПОНЯТЬ. См. выше отличный пример про BDSM.
Есть такая категория переводчиков, которые стремятся писать по-английски, но русскими словами и пунктуацией. Некоторые даже утверждают, что так «правильно» переводить художественные тексты. Правда как всегда где-то посередине. В любом случае, для того, чтобы ХОРОШО перевести текст, его придется спера ПОНЯТЬ. См. выше отличный пример про BDSM.
+1
Спасибо, постарался исправить замечания.
0
Ну а что ж Вы корректный перевод не указали?
Это Сан-Франциско. Здесь все увлечены распределенными системами и BDSM.
+2
Это такой известный прием — заставьте своего оппонента выглядеть косноязычно. Например, попросив его без подготовки объяснить что-то очень сложное кому-то очень некомпетентному.
+3
Монговато букв, но плюсанул)) «Усложнять — просто. Упрощать — сложно» (с).
+3
Из текста того же автора, но уже без сатиры:
It’s really not unreasonable to look at the whole Docker and container thing and conclude that it’s all bullshit.
Except it’s not.
It’s actually the future of how we build applications.
+4
Статье уже больше полугода, многое изменилось!
+3
Про сеть забыли!
Что бы оркестрировать сеть — нужно построить оверлейную SDN сеть, например на OpenContrail, оно как раз прекрасно дружит с Kubernetes.
Что бы оркестрировать сеть — нужно построить оверлейную SDN сеть, например на OpenContrail, оно как раз прекрасно дружит с Kubernetes.
+4
Это не Кэти Перри песня, а Карли Рей Джепсен же. Это важно.
+5
Недавно на /sysadmin наткнулся на девопсовкий цитатник про это самое:
“Re the LXD discussion above. I totally agree about containers being the best way to virtualize machines, and I can’t wait to start using it when Sun integrate it into Solaris ten years ago.”
+1
Вы вот смеётесь, а мне сейчас один клиент мОзги клепает что чтобы переслать XMLку от одного приложения к другому, вероятно на одной и той же машине, нужно поднять SOAP Server (как он это называет). И если начать думать про все возможные alternative и exception flows, то становится уже как-то совсем не смешно.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Это будущее