С другой стороны, теги хранимые внутри файла имеют свое ограничение.
— Вот формат файла, в котором нет тегов и метаинформации вообще.
— А вот, в котором нет тегов, но есть информация об авторе
— А здесь есть и настраиваемые теги и автор.
— А тут, есть теги и год издания, но нет автора.
— и т.д.
Итого у нас 1001 формат файлов, и у каждого своя уникальная структура хранения метаинформации, и не везде она совместима для удобной фильтрации и сортировки.
Т.е. как не реализуй, но все равно придет такой себе Josh Marinacci и скажет: «Что это за фигня, мне это не удобно, Ideal OS должна быть совсем не такой»
По поводу mp3, на самом деле раздражает, что даже в пределах одного альбома, и даже не скаченного где-то с пиратского сайта, а официально купленного, у соседних файлов теги могут различаться. В результате плееры, которые сортируют такие файлы по тегам, показывают две папки для одного концерта, вместо одной.
Как по мне, то если говорить о некой «правильной» реализации, то тэги обязаны быть частью файловой системы, при этом они обязаны быть однозначно привязаны и к файлу. Т.е. при копировании, архивировании и прочих действиях с файлом метаинформация о файле не должна портиться, а должна так-же сохраняться/архивироваться/передаваться.
Желание сохранять метаинформацию в самих файлах понятно, и конечно, как было сказано, полно файловых форматов, предполагающих сохранение такой информации. Но вот ведь в чем вопрос, получается, что файлы не предполагающие сохранение такой информации, такую информацию не сохраняют (простите за тавталогию).
К сожалению, смею предположить, что таких файловых форматов сейчас все же наверное большинство.
С тегами есть одна маленькая проблема, порой разные слова испоьзуются как теги с одним смыслом. К примеру далеко не факт что поиск по словам «отпуск египет 2017г фотки» выдаст файлы с тегами «отдых Египет 2017 фотографии».
Ой, только не говорите мне, что я, как пользователь, обязан помнить все теги, что я присваивал файлам 2 года назад.
На улице 2017 год. Я не понимаю, почему я должен готовить обед сам? Мне уже давно его должны готовить роботы. И на отдых я хочу летать на Марс! Это же так просто, запустить космические корабли туда. Да, и почему я не могу в свой старый жигули залить вместо бензина воду, и поехать. Бензин и вода — жидкие! Я не вижу никаких проблем в совместимости между ними!
То, что ты описал в первом примере — бывает. Но это далеко не тренд. В последнее время я вижу сильно много сеньеров, которые стали сеньерами, потому что долго в компании работают. Нет, они конечно работают неплохо, свои деньги в данной компании отрабатывают, но вот брать бы их на сеньерскую должность в новый проект, со сменой технологии и языка — нет уж, увольте.
1. Хороший программист сможет освоить новый язык довольно быстро — это правда. Вот только нюансы языка даже за 2 месяца освоить не получится. А сеньёр/техлид отличается от мидла именно знаниями этих нюансов.
2. Мой опыт говорит, что если человек способен за 1-2 недели выучить язык, то никто не будет его держать на джуниорской позиции больше, т.к. он просто уйдет. икакая вменяемая IT компания не хочет терять хороших программистов.
3. Я бы еще понял, если бы эта статья была написана программистом. Но в заголовке я вижу:
руководитель программистов (нанимался и нанимал)
Возникает вопрос, неужели автор этого текста нанял бы себе на проект на позицию Perl сеньёра/техлида того, кто раньше писал только на PHP и Perl в первый раз видит? Что-то у меня смутные сомнения.
Рюкзак в метро нужно снимать не всегда. Когда вагон полупустой, а у тебя не этот ужас толщиной наверное сантиметров 30, а нормальный городской рюкзак толщиной сантиметров 10, то можно спокойно стать спиной/рюкзаком к стенке, и вуаля, ты место занимаешь почти столько же, как и без рюкзака.
Более того, скажу страшную вещь. Люди порой рюкзаки на пузе носят, потому что так носить удобно, когда постоянные пересадки или через толпу двигаться нужно.
Да, и еще, карман для телефона на спине, это так задумано, чтобы его было легче доставать, когда тебе звонят или телефон понадобился?
На самом деле, проблема этой статьи видна уже в первой строке:
Заинтересовался темой функционального программирования, увидел здесь статью, и решил перевести
Проблема не в том, что статья плохая, неправильная и т.д. А в том, что для того, чтобы сравнивать достоинства и недостатки различных подходов программирования нужно потратить хотя бы пару лет используя эти подходы на практике. Причем практика должна быть не уровня «Hello world», а реальные и желательно большие проекты, чтобы писать их не в одиночку стдя на удобном диване, а в команде из хотя бы нескольких человек, и что бы то, что вы пишите потом интегрировалось с кодом написанным другими командами.
Кстати, почему решили, что locked обязано быть boolean? А если это 3-х позиционный замок: открыто, закрыто, открыто но на цепочке? И вот, весь показанный бонус от ФП пошел лесом. В то время как в солучае ООП мы проблем не получили.
Для новичка они ужасны, т.к. вместо того, чтобы показать в чем достоинство ФП, они будут смотреть на этот пример с дверью не понимая, нафига козе баян.
Но самое главное. Все эти попытки противопоставления ФП и ООП, они подобны потивопоставлению картошки и апельсин. Зачем они?
Switch будет проигрывать полноценным приставкам типа PS* или XBox* просто в силу размера и мощности. С другой стороны мощностей современных носимых приставок хватает для игр, которые для них пишутся. Т.е. единственное на чем может вылезти Switch это игры, которые будут недоступны на других переносимых игровых приставках в силу недостатка мощности.
Да, это вполне себе нормальная такая ниша, подобная Nintendo DS. Но как ни крути, это всего-лишь ниша, а не какое-то уберновшество меняющее игровую индустрию.
— Вот формат файла, в котором нет тегов и метаинформации вообще.
— А вот, в котором нет тегов, но есть информация об авторе
— А здесь есть и настраиваемые теги и автор.
— А тут, есть теги и год издания, но нет автора.
— и т.д.
Итого у нас 1001 формат файлов, и у каждого своя уникальная структура хранения метаинформации, и не везде она совместима для удобной фильтрации и сортировки.
Т.е. как не реализуй, но все равно придет такой себе Josh Marinacci и скажет: «Что это за фигня, мне это не удобно, Ideal OS должна быть совсем не такой»
Желание сохранять метаинформацию в самих файлах понятно, и конечно, как было сказано, полно файловых форматов, предполагающих сохранение такой информации. Но вот ведь в чем вопрос, получается, что файлы не предполагающие сохранение такой информации, такую информацию не сохраняют (простите за тавталогию).
К сожалению, смею предположить, что таких файловых форматов сейчас все же наверное большинство.
Ой, только не говорите мне, что я, как пользователь, обязан помнить все теги, что я присваивал файлам 2 года назад.
2. Мой опыт говорит, что если человек способен за 1-2 недели выучить язык, то никто не будет его держать на джуниорской позиции больше, т.к. он просто уйдет. икакая вменяемая IT компания не хочет терять хороших программистов.
3. Я бы еще понял, если бы эта статья была написана программистом. Но в заголовке я вижу:
Возникает вопрос, неужели автор этого текста нанял бы себе на проект на позицию Perl сеньёра/техлида того, кто раньше писал только на PHP и Perl в первый раз видит? Что-то у меня смутные сомнения.
Более того, скажу страшную вещь. Люди порой рюкзаки на пузе носят, потому что так носить удобно, когда постоянные пересадки или через толпу двигаться нужно.
Да, и еще, карман для телефона на спине, это так задумано, чтобы его было легче доставать, когда тебе звонят или телефон понадобился?
Т.е. я не хочу ничего плохого говорить про PHP или иной язык, но оценивать качество языка по его распространению… ну не знаю.
Быстрый взлет говорит не о качестве, а о простоте вхождения.
Респект
Проблема не в том, что статья плохая, неправильная и т.д. А в том, что для того, чтобы сравнивать достоинства и недостатки различных подходов программирования нужно потратить хотя бы пару лет используя эти подходы на практике. Причем практика должна быть не уровня «Hello world», а реальные и желательно большие проекты, чтобы писать их не в одиночку стдя на удобном диване, а в команде из хотя бы нескольких человек, и что бы то, что вы пишите потом интегрировалось с кодом написанным другими командами.
Но самое главное. Все эти попытки противопоставления ФП и ООП, они подобны потивопоставлению картошки и апельсин. Зачем они?
Switch будет проигрывать полноценным приставкам типа PS* или XBox* просто в силу размера и мощности. С другой стороны мощностей современных носимых приставок хватает для игр, которые для них пишутся. Т.е. единственное на чем может вылезти Switch это игры, которые будут недоступны на других переносимых игровых приставках в силу недостатка мощности.
Да, это вполне себе нормальная такая ниша, подобная Nintendo DS. Но как ни крути, это всего-лишь ниша, а не какое-то уберновшество меняющее игровую индустрию.