Даже «драйверы на С», которые становятся в каждом подобном споре тяжелым аргументом, тем не менее, я не вижу в написании драйвера каких-то фундаментальных отличий, от разработки веб-сервиса на PHP, который обменивается данными с другим сервером через XML. Казалось бы, что тут нет никаких аналогий. Но мне хватило начальных знаний C для того, чтобы написать службу уровня ядра (по сути — драйвер) для Windows XP, которая работала с системными структурами данных и обменивалась ими через обычные интерфейсы, как драйверы.
Я хочу сказать, что на самом деле написание драйвера и прошивки микроконтроллера, например, это не такие уж и сложные задачи, чтобы их можно было вот так просто ставить в противовес. Особенно, когда они разрабатываются по спецификации железа (другими словами — всегда), а сам процесс это просто кодинг интерфейса работы с железкой. Это уже не говоря о том, что начиная с Vista 64bit в Windows драйвера теперь запускаются на уровне пользователя и их программирование еще меньше отличается от написания обычных программ. А про linux и блочные/символьные устройства, я думаю, и говорить не стоит.
Я считаю, что современные средства разработки, фреймворки, скриптовые языки и множество доступных библиотек, решающих почти любую прикладную задачу
Уважаемый автор, не могли бы вы пояснить, что в этом списке делают «скриптовые языки»? Точнее не так, объясните мне, чем (даже в рамках написанного вами в статье) программирование на скриптовых языках отличается, по сути, от написания программ на С? Динамической типизацией? Управляемой памятью? Организацией работы с данными?
Мне вот интересно, неужели кто-то действительно думает, что проставлять тип перед переменной и указывать тип результата функции/метода это сложно? Или что сложно аллоцировать память перед использованием переменной определенного типа? Другой вопрос, в каких задачах это может быть плюсом, а в каких — минусом. Но тем не менее.
Я считаю, что это не более, чем частности, не более, чем какие-то признаки языка и сферы, в которой его можно использовать. Я, конечно, понимаю, что на JavaScript и PHP написать драйвер невозможно. Лично для меня интерпретируемые языки отличаются от компелируемых только наличием в первых eval-функций, которые я никогда в жизни не использовал, по правде говоря. В остальном же отличие скорее надуманное, потому что программирование, по сути, везде одинаковое. Просто в рамках одних проектов проще взять какие-то части (организация работы веб-сервера, организация работы клиента) как «черный ящик» и программировать другие части системы, бизнес-логику. Это все входит в одно большое понятие эффективности.
По моему мнению, языки программирования можно поделить только на такие группы — низкоуровневое программирование (ассемблеры), декларативное программирование и императивное программирование. Даже функциональное и процедурное, объектно-ориентированное, прототипно-ориентированное и что-то еще -ориентированное, это лишь признаки языка. Это становится очевидно тогда, когда на функциональных языках решаются императивные задачи, например. Все остальные отличия — статическая типизация, замыкания, динамическое классовое ООП, динамическое ООП на конструкторах — все это лишь частные случаи каких-то реализаций и на само программирование оказывают разве что косвенное влияние. Так же, как и разные разговорные языки почти не оказывают влияние на какую-то конкретную обсуждаемую тему.
Не хочу обидеть автора, но не понимаю смысла таких статей и исследований, в которых имеет место быть подмена понятий и неправильная установка акцентов. Ведь эти статьи потом находят в интернете люди, понимающие в программировании еще меньше, чем программисты, которые делают уязвимые сайты на PHP.
Когда потенциальные заказчики проводят собственные «исследования» вопроса, касательно сайтов, они могут найти статью, подобную этой, и сделать вывод, что сайты не нужно делать на PHP, потому что он — говно. Но вы же понимаете, что это проблема никак не языка и не технологии, а исключительно исполнителя по этим конкретным сайтам. Уязвимостей в самом PHP было не так уж и много и не многие из них были критичными по части безопасности. Но прочитав эту статью можно решить, что для безопасности сайта, лучше его делать на Java или APS.NET, тогда не будет уязвимости.
Вытекает это все в то, что заказчик, собираясь открывать интернет магазин, начинает искать исполнителей, которые выполнят эту работу на технологиях Java/.NET, игнорируя PHP и считая специалистов в этом языке какими-то новичками с дырявыми руками и головами. Т.е., всех. Уровень серьезного отношения к PHP падает с каждым годом, при том, что число заказов растет. Хорошо ли это?
Это приводит к тому, что сама по себе разработка таких проектов теряет эффективность. И совсем не потому, что на Java/.NET могут программировать только истинные специалисты с сертификатами от microsoft, лично для меня уже давно не существует понятия «сложность языка», потому что программирование везде одинаковое, по сути (если речь не идет о декларативных и функциональных ЯП). А потому, что для конкретного круга задач использовать PHP можно эффективнее, чем в общих равных использовать JSP/ASP. Просто потому, что Java/.NET избыточны для многих задач, количество специалистов с опытом на этих технологиях меньше, а значит поддержка и программное сопровождение проекта будет дороже, не говоря уже о том, что срок разработки на этих технологиях обычно ставится больший, чем в случае PHP, хотя их использование не намного сложнее.
Уровень «безопасности» тут диктуется только тем, что использование этих платформ накладывает определенные архитектурные ограничения, особенно при использовании фреймворков, которые не позволяют попасться на «новичковые» ошибки. Например, используя ORM вряд ли можно столкнуться с SQL-injection, но это не значит, что используют их программисты «высшей лиги», ведь человек, который всю жизнь работает с базами через интерфейс и ORM может вообще не знать, в чем суть самой ошибки недостаточной фильтрации данных и как это становится уязвимостью на сайте. Как и в managed программах, человек может вообще не знать, что такое переполнение буффера и как оно происходит и по какой причине.
Конечно, уязвимости есть везде. И вообще, я уверен, что неуязвимый код один специалист в сколько-либо большом проекте написать неспособен, независимо от его квалификации. Даже если руководствоваться принципами безопасной разработки, ошибки и уязвимости будут всплывать почти всегда. Вспомните, например, есть opensource проекты которые десятки лет поддерживались сообществом, но даже через 10 лет иногда находили уязвимости архитектуры, или уязвимости в участках кода, который успешно эксплуатировался несколько лет и даже был покрыт тестами.
Конечно, отчасти вы правы. С увеличением популярности среди пользователей, растет и популярность среди вирусописателей. Но эта зависимость не всегда значит то, что «никто не пишет вирусы, потому что не нужно». Возьмите, например, MacOS. Да будет вам известно, что в европе/США большая половина всех предпринимателей, глав корпораций, просто работников различных контор, а так же студентов хороших ВУЗов используют продукцию Apple в качестве десктопов/ноутбуков/нетбуков/планшетных компьютеров. Это продукция достаточно обеспеченной аудитории, часто очень обеспеченной, которые довольно часто платят в интернете, у них могут храниться данные, которые можно использовать против них самих и так далее. Как правило, это более «активные» пользователи, чем домохозяйки с виндой. Прямо-таки рай для вирусов и троянцев, казалось бы. А как обстоит дело на самом деле?
Это разве атаки? Это детский сад, оружие против тех, кто не утруждает себя настройкой своего веб-сервера. Сетевому оборудованию этот «slow type» никаких проблем не создает, значит «отразить» эту атаку можно просто софтом на конечном сервере.
Боюсь, что асинхронность в вашем примере это многопоточность, а не асинхронность, как в Node.JS.
Приостанавливать работу текущей «задачи» в Node.JS нельзя, поскольку общая задача выполняется синхронно в одном потоке, который ожидание результата (синхронное) просто остановит. Если не использовать фибру, например, или подобные пакеты.
Вычисления не обязательно должны быть сложными, они вообще не обязательно должны быть «вычислениями», если вы понимаете, о чем я. Это могут быть любые операции, которые выполняются довольно часто, либо постоянно. Держать их в одном процессе вместе с веб-сервером будет накладно, а в некоторых случаях — невозможно.
JavaScript это нормальный язык, не менее нормальный, чем Python, который кстати на него довольно похож, например динамической моделью ООП. А описанное вами возможно только в случае, если асинхронный поток можно «слайсить» (я не знаю, какой тут термин подойдет) с помощью node-fibers, например. В tornado такой функционал является встроенным, хотя сам по себе не является частью «стандартного» асинхронного IO.
На вашем месте я бы обозначил еще одну проблему, которая для некоторых приложений может стать критической. Node.JS выполняет код асинхронно в одном процессе и одном потоке, несмотря на то, что сама event-машина работает асинхронно, ваш код, который отвечает на события не обладает этим свойством и асинхронность достигается только за счет асинхронных вызовов с установлением коллбека. Конечно, это не всегда минус, но и не всегда плюс. Я прекрасно понимаю, что это by design, а не ошибка. Но на это нужно обращать пристальное внимание, когда вы выбираете технологию для разработки, поскольку в больших приложениях вам придется мыслить «процессами», а встроенная возможность запускать дочерние процессы и разделять использование порта между процессами не решает многих проблем, например проблем с comet-серверами на основе сессий, а не каналов. И некоторых других (когда данные обрабатываются в памяти, а не записываются в БД).
Если ваше приложение использует не только логику запроса-ответа, как интерфейс к базе данных, а содержит какую-либо бизнес-логику на JavaScript, то для повышения быстродействия вам придется продумывать горизонтальное расширение заранее, либо вычленять отдельные участки кода и запускать в отдельных процессах, взаимодействия с ними с помощью систем очередей, или по паттерну publisher/subscriber. Или, как минимум, следовать логике встроенного раздельного использования порта в веб-сервере, а более сложную логику всю перенести в отдельный сервис, запускающийся в своем процессе.
Еще одним минусом я считаю низкое качество и количество библиотек. Это, конечно, временно, но в некоторые даже часто используемые библиотеки мне приходилось отсылать коммиты, исправляющие довольно простые и очевидные неточности, которые приводили к проблемам, в т.ч. с утечками памяти.
Защита детей — первоочередная задача как государственного уровня, так и уровня семьи. Сексуальное насилие настолько распространено, что все остальные проблемы на его фоне меркнут. Кто-то пытается реформировать образование, возвращать помещения детским садам, открывать новые, пропагандировать нравственность в школах, вовлекать детей в какую-то интересную деятельность, на основе «кружков». Я считаю — глупости, начать надо с того, что кастрировать всех педофилов. Я не могу представить себе такой мир, где ребенка нельзя даже послать в магазин за водкой, или сигаретами, зная, что его может изнасиловать педофил. Или как можно ребенка отправить в переход метро раздавать флаеры, если какой-нибудь педофил его может выкрасть? Как вообще родители могут спокойно, после тяжелого рабочего дня, выпить водку и посмотреть вечерние новости, если есть опасность педофилии? Я считаю, что весь народ должен объединиться перед этой проблемой, которая, несомненно, затрагивает всех нас, в каждой семье может быть педофил. Педофилы просто везде, в школе это тоже очень важная проблема, нужно преподавать христианские учения и следить за всеми преподавателями мужского пола, ведь они могут быть педофилами. Кроме того, мне страшно за всех этих брошенных детей, которые воспитаются в детдомах. Так и так не сладко, финансирования нет, все здания полуразрушенные, никакого обустройства совершеннолетних выходцев из дет. домов нет, но это все плевать, самое страшное — они являются целями педофилов, ведь им просто никто не может помочь, в случае чего! Это страшно, господа. Я не только за последние изменения в законодательстве, но я также всецело поддерживаю пропаганду анти-педофилии во всех сми и не только. Каждый должен знать о самом большом враге человека — педофиле. По опыту цивилизованных стран нужно ввести публичные списки сексуальных преступников и вводить туда всех, кто не только уличен в действиях сексуального характера, но и кто просто неоднозначно прикоснулся к ребенку, или оказал ему знак внимания. Так же, реальные сроки нужно давать тем, кто просматривает детское порно, или даже пользуется скрытыми файлообменными сетями, потому что там одни педофилы. Кастрирование каждому педофилу без исключения, искореним заразу, сожжем их на костре.
Вы это серьезно сейчас сказали, или это такой юмор?
Просто такие детские «досы» на серверах с базовой настройкой nginx обычно проходят незамеченными. Под базовой я имею в виду хотя бы limit_req_zone+limit_req в зависимости от максимальной возможной нагрузки с одного айпи на сайт. Я, например, сомневаюсь что сайту без монструозной посещаемости потребуется обрабатывать больше 3х запросов в секунду (с прыжками до 5 запросов) с одного айпи адреса. От всяких LOIС и других генераторов траффика это достаточная защита. Как и от ддоса с 10-20 прокси.
Это не бага, просто массив это структура, в которой численные ключи генерируются из порядкового номера значения. Когда вы записываете значение по ключу и используете его вроде как хеш, но не массив, вы и приводите к таким ситуациям. Это кстати свойственно не только JavaScript. А суть вся скорее всего в том, что внутри forEach() (который создан для обхода массивов, а значит 0..n) логика завязана на length, а как всем известно: var a = [];
a[10000000] = 1;
a.length; // 10000001
Я хочу сказать, что на самом деле написание драйвера и прошивки микроконтроллера, например, это не такие уж и сложные задачи, чтобы их можно было вот так просто ставить в противовес. Особенно, когда они разрабатываются по спецификации железа (другими словами — всегда), а сам процесс это просто кодинг интерфейса работы с железкой. Это уже не говоря о том, что начиная с Vista 64bit в Windows драйвера теперь запускаются на уровне пользователя и их программирование еще меньше отличается от написания обычных программ. А про linux и блочные/символьные устройства, я думаю, и говорить не стоит.
Уважаемый автор, не могли бы вы пояснить, что в этом списке делают «скриптовые языки»? Точнее не так, объясните мне, чем (даже в рамках написанного вами в статье) программирование на скриптовых языках отличается, по сути, от написания программ на С? Динамической типизацией? Управляемой памятью? Организацией работы с данными?
Мне вот интересно, неужели кто-то действительно думает, что проставлять тип перед переменной и указывать тип результата функции/метода это сложно? Или что сложно аллоцировать память перед использованием переменной определенного типа? Другой вопрос, в каких задачах это может быть плюсом, а в каких — минусом. Но тем не менее.
Я считаю, что это не более, чем частности, не более, чем какие-то признаки языка и сферы, в которой его можно использовать. Я, конечно, понимаю, что на JavaScript и PHP написать драйвер невозможно. Лично для меня интерпретируемые языки отличаются от компелируемых только наличием в первых eval-функций, которые я никогда в жизни не использовал, по правде говоря. В остальном же отличие скорее надуманное, потому что программирование, по сути, везде одинаковое. Просто в рамках одних проектов проще взять какие-то части (организация работы веб-сервера, организация работы клиента) как «черный ящик» и программировать другие части системы, бизнес-логику. Это все входит в одно большое понятие эффективности.
По моему мнению, языки программирования можно поделить только на такие группы — низкоуровневое программирование (ассемблеры), декларативное программирование и императивное программирование. Даже функциональное и процедурное, объектно-ориентированное, прототипно-ориентированное и что-то еще -ориентированное, это лишь признаки языка. Это становится очевидно тогда, когда на функциональных языках решаются императивные задачи, например. Все остальные отличия — статическая типизация, замыкания, динамическое классовое ООП, динамическое ООП на конструкторах — все это лишь частные случаи каких-то реализаций и на само программирование оказывают разве что косвенное влияние. Так же, как и разные разговорные языки почти не оказывают влияние на какую-то конкретную обсуждаемую тему.
Когда потенциальные заказчики проводят собственные «исследования» вопроса, касательно сайтов, они могут найти статью, подобную этой, и сделать вывод, что сайты не нужно делать на PHP, потому что он — говно. Но вы же понимаете, что это проблема никак не языка и не технологии, а исключительно исполнителя по этим конкретным сайтам. Уязвимостей в самом PHP было не так уж и много и не многие из них были критичными по части безопасности. Но прочитав эту статью можно решить, что для безопасности сайта, лучше его делать на Java или APS.NET, тогда не будет уязвимости.
Вытекает это все в то, что заказчик, собираясь открывать интернет магазин, начинает искать исполнителей, которые выполнят эту работу на технологиях Java/.NET, игнорируя PHP и считая специалистов в этом языке какими-то новичками с дырявыми руками и головами. Т.е., всех. Уровень серьезного отношения к PHP падает с каждым годом, при том, что число заказов растет. Хорошо ли это?
Это приводит к тому, что сама по себе разработка таких проектов теряет эффективность. И совсем не потому, что на Java/.NET могут программировать только истинные специалисты с сертификатами от microsoft, лично для меня уже давно не существует понятия «сложность языка», потому что программирование везде одинаковое, по сути (если речь не идет о декларативных и функциональных ЯП). А потому, что для конкретного круга задач использовать PHP можно эффективнее, чем в общих равных использовать JSP/ASP. Просто потому, что Java/.NET избыточны для многих задач, количество специалистов с опытом на этих технологиях меньше, а значит поддержка и программное сопровождение проекта будет дороже, не говоря уже о том, что срок разработки на этих технологиях обычно ставится больший, чем в случае PHP, хотя их использование не намного сложнее.
Уровень «безопасности» тут диктуется только тем, что использование этих платформ накладывает определенные архитектурные ограничения, особенно при использовании фреймворков, которые не позволяют попасться на «новичковые» ошибки. Например, используя ORM вряд ли можно столкнуться с SQL-injection, но это не значит, что используют их программисты «высшей лиги», ведь человек, который всю жизнь работает с базами через интерфейс и ORM может вообще не знать, в чем суть самой ошибки недостаточной фильтрации данных и как это становится уязвимостью на сайте. Как и в managed программах, человек может вообще не знать, что такое переполнение буффера и как оно происходит и по какой причине.
Конечно, уязвимости есть везде. И вообще, я уверен, что неуязвимый код один специалист в сколько-либо большом проекте написать неспособен, независимо от его квалификации. Даже если руководствоваться принципами безопасной разработки, ошибки и уязвимости будут всплывать почти всегда. Вспомните, например, есть opensource проекты которые десятки лет поддерживались сообществом, но даже через 10 лет иногда находили уязвимости архитектуры, или уязвимости в участках кода, который успешно эксплуатировался несколько лет и даже был покрыт тестами.
Вот вам ссылочка для ознакомления с транскрипцией.
Приостанавливать работу текущей «задачи» в Node.JS нельзя, поскольку общая задача выполняется синхронно в одном потоке, который ожидание результата (синхронное) просто остановит. Если не использовать фибру, например, или подобные пакеты.
Если ваше приложение использует не только логику запроса-ответа, как интерфейс к базе данных, а содержит какую-либо бизнес-логику на JavaScript, то для повышения быстродействия вам придется продумывать горизонтальное расширение заранее, либо вычленять отдельные участки кода и запускать в отдельных процессах, взаимодействия с ними с помощью систем очередей, или по паттерну publisher/subscriber. Или, как минимум, следовать логике встроенного раздельного использования порта в веб-сервере, а более сложную логику всю перенести в отдельный сервис, запускающийся в своем процессе.
Еще одним минусом я считаю низкое качество и количество библиотек. Это, конечно, временно, но в некоторые даже часто используемые библиотеки мне приходилось отсылать коммиты, исправляющие довольно простые и очевидные неточности, которые приводили к проблемам, в т.ч. с утечками памяти.
Просто такие детские «досы» на серверах с базовой настройкой nginx обычно проходят незамеченными. Под базовой я имею в виду хотя бы limit_req_zone+limit_req в зависимости от максимальной возможной нагрузки с одного айпи на сайт. Я, например, сомневаюсь что сайту без монструозной посещаемости потребуется обрабатывать больше 3х запросов в секунду (с прыжками до 5 запросов) с одного айпи адреса. От всяких LOIС и других генераторов траффика это достаточная защита. Как и от ддоса с 10-20 прокси.
var a = [];a[10000000] = 1;
a.length; // 10000001
И тому, кто одалживает, и для тех, кто берет в долг.