Просто любопытно, а по какой статье отправят на Колыму за продажу фиктивных ПД?
Если по принципу «был бы человек, а статья найдётся» — то никто не мешает вести сайт вне зоны досягаемости ФСБ, особенно с учётом того что до него не будет дела никому кроме как в РФ. Если госорганы РФ сделают запрос хостеру на выдачу данных о владельце, то в адекватной стране их отправят за решением местого суда, на этом след оборвётся, и даже если нет — что они сделают условному американцу, который формально ничего не нарушил?
А простым гражданам — вести журнал, кому, когда и что передал.
Если речь про стандартный набор (ФИО, дата рождения, адрес и телефон, иногда ИНН) — то вести журнал не имеет смысла, потому что эти данные нужны почти всем, и выяснить у кого именно утечка невозможно.
Если на каждую передачу данных давать новый номер телефона, и если он утечет — можно выяснить источник, но это непрактично, но даже в этом случае останется как минимум два варианта — либо телефонный провайдер, либо тот кому был дан телефон.
Собственно, это фундаментальная проблема всех ПД — они весьма стабильны, и почти все операторы имеют идентичный набор данных, без индивидуальных маркеров.
Отследить можно только утечки данных с маркером (биллинг, выписки etc) — но опять-таки, этого мало. Если условный злодей где-то нашел скан паспорта и стандартный набор, то вариантов слишком много (для среднего потребителя).
Я не утверждаю что операторы все такие белые и пушистые (хотя гораздо белее и пушистее чем в СНГ), просто оно того не стоит — даже десятка недовольных абонентов, которые могут задокументировать и доказать подобные случаи, хватит чтобы оператор потерял больше чем получит с них за несколько лет. Всё же законы в Германии хорошо работают, защита потребителей тоже.
Это утверждение несколько сомнительно. Я живу в Германии и у меня 4 мобильных номера, за последние 15 лет каждый из них сменил оператора как минимум по три раза, и никогда подобного безобразия не было.
Самое худшее что было — это назойливые звонки и уговоры остаться, несмотря на явную просьбу больше не звонить.
Что касается выборочного ухудшения качества связи — если она действительно так ухудшится (хотя и не представляю, как это технически реализовать, кроме интернеа), причём в местах где покрытие отличное, и это ухудшение будет стабильным, то это может стать основанием для досрочного разрыва договора (были уже прецеденты).
Уже который раз удивляет стоимость жилья — что в Англии, что в Ирландии. В Германии (Дюссельдорф, черта города, хороший район, хоть и не центр) аренда дома стоит €2000 (150 кв.м, включая участок около 70 кв.м., гараж, электроэнергию и отопление), а тут 40 кв.м. однушка более чем за €1500? Нет слов…
Я не вижу драмы — иначе бы не существовало кучи проектов на Perl и он бы не был популярен в принципе (никогда), а сам факт того что он использовался и используется говорит о том что невозможность статического парсинга вовсе не помеха.
Мне лично гораздо более неприятно то что в C/C++ неопределен порядок вычисления аргументов функций (да и вообще выражений) — вот это действительно драма, по сравнению с динамическим парсингом, потому что, в отличие от динамического парсинга, это вообще непредсказуемо, но это никого не смущает:
(a++)+(++a)+(a--)+(--a)
Такое выражение даст разные результаты в зависимости от платформы, компилятора, его версии или настроек оптимизации — но почему-то допускается, несмотря на возможность статического парсинга.
Вы можете возразить — «не надо такое использовать» — так что же мешает не использовать особенности Perl, в таком случае?
Если темплейты (конкретный результат) не может понять любой человек, который знаком с языком — то это проблема этого человека.
Чтобы код был понятен всем, существуют style guide, никакой язык не заставит писать код который понятен всем (разве что там всего несколько строк).
Возьмите любой проект на js, пропустите через минимизатор (и оптимизатор) — и удачи в понимании его смысла, особенно если это библиотека типа jquery. И сейчас скажите что проблема в языке? Что примечательно, некоторые так пишут сами, на разных языках…
Мне кажется страшным не само ограничение, а его принудительность — потому что бывают ситуации когда оно мешает (маневр для ухода от столкновения, к примеру, экстренный обгон etc). Я имел в виду именно физическое ограничение — т.е. случай когда автомобиль «залочен» на скорости до 50 или сам останавливается на знаке STOP, или даже ещё хуже — тупо останавливается на красный и начинает ехать на зеленый (тоже сам).
Есть языки которые позволяют делать operator overloading, а есть которые не позволяют — причиной называется то что это «может запутать» и «ухудшает читабельность» — хотя в ряде случаев как раз наоборот, то же самое относится к goto — это вопрос вкуса, если угодно.
Точно также и с Perl — может в ряде случаев это и ухудшит ситуацию, но может и улучшить. В конкретном проекте легко выставить условие — «никаких сомнительных конструкций» — и всё, вопрос закрыт, а для внутренних скриптов-однодневок, экспериментов или кода который ограничен по времени или памяти это может быть только плюсом.
Лучше иметь в баре бутылку виски и не пить его, чем не иметь и вдруг обнаружить что хочется выпить (опасность тут только для алкоголиков).
Погуглите codegolf %language% — найдете массу примеров, когда вы не сможете понять что происходит не выполняя код (а иногда и выполняя), практически на любом языке, несмотря на то что синтаксис легко разбирается.
Для меня, к примеру, являются практически нечитаемыми (= невозможно понять) навороченные многоуровневые темплейты в C++, их явно понимает только автор, но это ведь не проблема языка.
В энтерпрайзной разработке не должно быть никакого «творчества на уровне языка».
Я вас сильно удивлю, если скажу что есть и другие виды разработок?
Ограничения должны быть административными — как и в ПДД. Представьте что автомобили физически ограничены двигаться не более 50 км/ч в городе, или принудительно останавливаются на знаке STOP — это нормально будет?
А каким образом возраст языка определяет его актуальность?
PHP всего на 7 лет младше Perl, но ведь ещё актуален? И это несмотря на то что его ругают все кому не лень (причём за дело).
Си вообще почти древний (аж на 15 лет старше Perl) — и что, он уже неактуален?
Что касается «не пойдёт на вакансию» — это зависит от задачи и оплаты. Уверен, что если будет выбор между «CMS для порносайта» на C# за $50/час или «AI для робомобиля» на Perl за $75/час — то вряд ли многие выберут порносайты, даже если не знают Perl. Хотя, если это простые банальные кодеры — то да, выберут. А хорошие разработчики все же выберут второе.
Назову две — интересная задача и хорошая оплата. Интересность задачи с языком программирования редко коррелирует.
Хотя вообще-то хороший разработчик должен знать (т.е. уметь практически применять) несколько языков, и понимать намного больше (хотя бы со словарём), а также легко осваивать новые, иначе он просто узкоспециализированный кодер.
К несчастью, многие современные разработчики знают только один, любой другой (даже похожий) идёт с трудом, и шаг влево или вправо выбивает их из колеи. Печально.
В приведенном примере задача остановки может быть притянута за уши только если речь идёт о статическом парсинге (без выполнения). Неудивительно, что статический парсинг невозможен — но его никто не делает (и не собирается), соответственно, пример «дьявольского кода» с сопуствующим текстом — это всего лишь мысленные упражнения.
Да, язык это позволяет (потому что это фича), но не навязывает — не вижу проблемы. Вы же не запрещаете производство кухонных ножей просто потому что ими можно кого-то убить или порезаться? Да и лицензий или курсов обучения для пользования бытовыми ножами я что-то не встречал — но вот удивительное дело, это не приводит к проблемам, кроме изолированных частных случаев.
Как я уже говорил раньше, никакой язык не обеспечит идеальности кода без желания разработчика (или его начальника) — на любом, даже самом идеальном и зарегулированном донельзя языке можно написать полную хрень, никем кроме автора не читаемую и непонимаемую (но вполне работоспособную), но это само по себе не делает язык плохим или хорошим.
Не надо ограничивать творчество на уровне языка — злые гении всё равно найдут выход, а добрые обидятся и не сделают чего-то великого в момент озарения.
Хороший разработчик на C/C++/Java/C#/JS/PHP без труда обучится Perl максимум за месяц — и это будет явно быстрее и дешевле чем портировать всё на новый стек.
Ужасные языки — это brainfuck & co, а в остальных бывает только ужасный код, причём в любых. Ужасно могут выглядеть и Python и Go, в зависимости от уровня кодера (или его желания выпендриться), и куча кода на PHP (некоторые популярные плагины под WP, к примеру) просто за гранью добра.
Да, Perl позволяет создавать малочитаемый код, но это выбор разработчика, а не особенность языка. Если я пишу скрипт для себя из серии «написал и забыл» — это не проблема, а для проекта который уйдёт в свет и с которым будет работать команда можно писать чисто и понятно. Для этого, кстати, и нужно адекватное обучение.
Но смысла в этом оверхеде всё равно нет (он не такой уж и незначительный), если можно отдать block device.
Если по принципу «был бы человек, а статья найдётся» — то никто не мешает вести сайт вне зоны досягаемости ФСБ, особенно с учётом того что до него не будет дела никому кроме как в РФ. Если госорганы РФ сделают запрос хостеру на выдачу данных о владельце, то в адекватной стране их отправят за решением местого суда, на этом след оборвётся, и даже если нет — что они сделают условному американцу, который формально ничего не нарушил?
Если речь про стандартный набор (ФИО, дата рождения, адрес и телефон, иногда ИНН) — то вести журнал не имеет смысла, потому что эти данные нужны почти всем, и выяснить у кого именно утечка невозможно.
Если на каждую передачу данных давать новый номер телефона, и если он утечет — можно выяснить источник, но это непрактично, но даже в этом случае останется как минимум два варианта — либо телефонный провайдер, либо тот кому был дан телефон.
Собственно, это фундаментальная проблема всех ПД — они весьма стабильны, и почти все операторы имеют идентичный набор данных, без индивидуальных маркеров.
Отследить можно только утечки данных с маркером (биллинг, выписки etc) — но опять-таки, этого мало. Если условный злодей где-то нашел скан паспорта и стандартный набор, то вариантов слишком много (для среднего потребителя).
К тому же, с 2016 года провайдерам запретили навязывать клиентам своё оборудование, и все желающие имеют возможность поставить то что хотят.
Насчёт QoS — не уверен что кто-то будет этим заморачиваться ради 15 евро/мес., к тому же это только укрепит клиента в мыслях что нужно уходить.
Самое худшее что было — это назойливые звонки и уговоры остаться, несмотря на явную просьбу больше не звонить.
Что касается выборочного ухудшения качества связи — если она действительно так ухудшится (хотя и не представляю, как это технически реализовать, кроме интернеа), причём в местах где покрытие отличное, и это ухудшение будет стабильным, то это может стать основанием для досрочного разрыва договора (были уже прецеденты).
Мне лично гораздо более неприятно то что в C/C++ неопределен порядок вычисления аргументов функций (да и вообще выражений) — вот это действительно драма, по сравнению с динамическим парсингом, потому что, в отличие от динамического парсинга, это вообще непредсказуемо, но это никого не смущает:
Такое выражение даст разные результаты в зависимости от платформы, компилятора, его версии или настроек оптимизации — но почему-то допускается, несмотря на возможность статического парсинга.
Вы можете возразить — «не надо такое использовать» — так что же мешает не использовать особенности Perl, в таком случае?
Чтобы код был понятен всем, существуют style guide, никакой язык не заставит писать код который понятен всем (разве что там всего несколько строк).
Возьмите любой проект на js, пропустите через минимизатор (и оптимизатор) — и удачи в понимании его смысла, особенно если это библиотека типа jquery. И сейчас скажите что проблема в языке? Что примечательно, некоторые так пишут сами, на разных языках…
Есть языки которые позволяют делать operator overloading, а есть которые не позволяют — причиной называется то что это «может запутать» и «ухудшает читабельность» — хотя в ряде случаев как раз наоборот, то же самое относится к goto — это вопрос вкуса, если угодно.
Точно также и с Perl — может в ряде случаев это и ухудшит ситуацию, но может и улучшить. В конкретном проекте легко выставить условие — «никаких сомнительных конструкций» — и всё, вопрос закрыт, а для внутренних скриптов-однодневок, экспериментов или кода который ограничен по времени или памяти это может быть только плюсом.
Лучше иметь в баре бутылку виски и не пить его, чем не иметь и вдруг обнаружить что хочется выпить (опасность тут только для алкоголиков).
Для меня, к примеру, являются практически нечитаемыми (= невозможно понять) навороченные многоуровневые темплейты в C++, их явно понимает только автор, но это ведь не проблема языка.
Я вас сильно удивлю, если скажу что есть и другие виды разработок?
Ограничения должны быть административными — как и в ПДД. Представьте что автомобили физически ограничены двигаться не более 50 км/ч в городе, или принудительно останавливаются на знаке STOP — это нормально будет?
callback hell, впрочем, следствие непонимания или неправильного использования асинхронных фич, но всё можно делать правильно.
PHP всего на 7 лет младше Perl, но ведь ещё актуален? И это несмотря на то что его ругают все кому не лень (причём за дело).
Си вообще почти древний (аж на 15 лет старше Perl) — и что, он уже неактуален?
Что касается «не пойдёт на вакансию» — это зависит от задачи и оплаты. Уверен, что если будет выбор между «CMS для порносайта» на C# за $50/час или «AI для робомобиля» на Perl за $75/час — то вряд ли многие выберут порносайты, даже если не знают Perl. Хотя, если это простые банальные кодеры — то да, выберут. А хорошие разработчики все же выберут второе.
Хотя вообще-то хороший разработчик должен знать (т.е. уметь практически применять) несколько языков, и понимать намного больше (хотя бы со словарём), а также легко осваивать новые, иначе он просто узкоспециализированный кодер.
К несчастью, многие современные разработчики знают только один, любой другой (даже похожий) идёт с трудом, и шаг влево или вправо выбивает их из колеи. Печально.
Да, язык это позволяет (потому что это фича), но не навязывает — не вижу проблемы. Вы же не запрещаете производство кухонных ножей просто потому что ими можно кого-то убить или порезаться? Да и лицензий или курсов обучения для пользования бытовыми ножами я что-то не встречал — но вот удивительное дело, это не приводит к проблемам, кроме изолированных частных случаев.
Как я уже говорил раньше, никакой язык не обеспечит идеальности кода без желания разработчика (или его начальника) — на любом, даже самом идеальном и зарегулированном донельзя языке можно написать полную хрень, никем кроме автора не читаемую и непонимаемую (но вполне работоспособную), но это само по себе не делает язык плохим или хорошим.
Не надо ограничивать творчество на уровне языка — злые гении всё равно найдут выход, а добрые обидятся и не сделают чего-то великого в момент озарения.
Да, Perl позволяет создавать малочитаемый код, но это выбор разработчика, а не особенность языка. Если я пишу скрипт для себя из серии «написал и забыл» — это не проблема, а для проекта который уйдёт в свет и с которым будет работать команда можно писать чисто и понятно. Для этого, кстати, и нужно адекватное обучение.