Не склонен с вами согласится: ваша претензия скорее не к языкам с динамической типизацией, а к скриптовым языкам в принципе. Да, из соображений скорости проверка кода идет в 2 приема, при загрузке модуля на синтаксические ошибки, и в процессе работы на присутствие/отсутствие свойств и методов. Вы не хотите задуматься о смене языка на статически типизированный, раз со скриптами вам неудобно?
К стати, определенная работа по преодолению этих недостатков идет: например в php поддерживает тайпхинты, да и в питоне есть модуль typing с аналогичными возможностями. Правда я не знаю, на сколько эти технологии устоявшиеся, потому что, пока, проще найти код без указания типов, чем с ними.
> 2.…
Ок, кому — то чисто позиционные параметры нужны, я, хоть и не согласился, но понял «зачем». Чего я точно не понимаю, и вообще, слегка в шоке, «почему так»? Ну приспичило вам вам запретить обращение к параметру по имени, ну так возьмите и пометьте каждый такой параметр каким нибудь значком, или даже слово служебное придумайте. Все остальные параметры тусуем как хотим, а этот желаем видеть только на третей позиции, к примеру, и ни как иначе.
> 4.…
То, что в текущей реализации словарь оставляет значения в порядке вставки, это, скорее детали реализации, нежели дизайна языка. На мой взгляд, плохая идея — использовать эту особенность в чем — то, что будет запускаться не только вами и не один — два раза.
Согласен с вами, странные плюшки.
1. Новый оператор требует, как минимум, тщательного объяснения его применимости. Даже приведенный пример с массивом, сколько людей способно понять, почему в этом случае он не сработает? Извращенный ум и шаловливые рученки могут породить еще массу вариантов, которые нужно будет проверять, прежде чем вставлять в реальный код. И кто выиграет от такого «улучшения»?
2. Было же простое и понятное правило, сначала идут позиционные, потом именованные аргументы. Зачем и кому потребовалась эта ужесть? Зачем в список параметров функции помещать что — то кроме параметров этой самой функции?
4. Поправьте меня, если я ошибаюсь, но есть просто dict и есть OrderedDict, который помнит порядок вставки. Если для второго — ок, наверное это кому — то нужно, то для первого ценность нововведения сомнительна, на мой взгляд.
П. п. 3 и 5 особой антипатии не вызывают, хотя, лично для меня, и особой ценности не представляют.
VM питона является стековой. Для, хотя бы, эмуляции параллельного исполнения приходится каждому "параллельному процессу" предлагать "свой" стек. Если произойдет исключение и мы его не поймаем, то начнется разматывание стека виртуальной машиной, которой сугубо пофиг дым на нашу "параллельность", ей про это ничего не известно.
Моя мысль была в том, что: нельзя бесконечно курочить продукт несвойственными ему функциями, чем дальше, тем чаще это будет выходить боком. Или у вас другое мнение?
реализация новомодных плюшек, вроде асинхронности или сопрограмм, желающие могут расширить этот список на свое усмотрение, на мой взгляд, является ни чем иным как хаком. когда язык придумывался вопроса о загрузке всех ядер процессора не стояло, и для этого в VM питона нет ничего.
чем сложнее вещь, тем проще ее поломать. достаточно только потерять осторожность. к новым плюшкам в питоне это тоже относится. генераторы — офигенно удобная абстракция, но не нужно забывать об осторожности. даже если мы просто засунем в генератор выборку данных из БД или сети, и забудем поймать какое либо исключение, как поведет себя программа? собьется алгоритм переключения стека или устоит? а если процесс долгоживущий? а если начать активно смешивать генераторы с асинхронными функциями и бросанием исключений? подозреваю что алгоритм сломается, вопрос только во времени, как скоро это случиться.
кто виноват, в том, что наш любимый язык иногда нас расстраивает? авторы? отчасти могут быть, особенно если языки создаются прямо сегодня. но python появился много лет назад, и всегда старался быть обратно совместимым с прошлыми версиями себя. естественно, чем дальше, тем может быть больше отрыв от сегодняшней реальности. не раз сталкивался с тем, что новые разработчики на python испытывают неоправданный оптимизм по отношению к языку, считая, "раз это заявлено и реализовано", значит это должно работать, какой бы код они ни написали. автор статьи, на мой взгляд, не плохо проиллюстрировал, что это не всегда так.
От "кто виноват" перейдем к "что делать":
критически переосмыслить ядро языка. что не является востребованным или является устаревшим — убрать. ни каких договоренностей, или часть синтаксиса и полноценно поддерживается, или ни где не упоминается (я, к примеру, о публичных и приватных свойствах классов). одна возможность должна реализовываться единственным образом (например, свойства классов описываем в конструкторе, вычислимые помечаем декоратором методы класса, и ни как иначе).
основной аргумент Гвидо, против внедрения многопоточности был, как я помню: "невозможно внедрить поддержку многопоточности так, чтобы это не отразилось на скорости однопоточных программ". но, если нельзя сделать одну универсальную программу, может стоит задуматься о двух?
если взяться за реализацию полноценной параллельности/конкурентности, то нужно понять, что это будет, отдельная библиотека, часть синтаксиса, нечто среднее.
можно попробовать замахнуться на распараллеливание, например, циклов, а не только запуск функций в отдельном потоке.
если подытожить сказанное выше: проект php-ng успешно вылился в обновление языка и это способствовало его развитию и появлению новых возможностей, нужны люди, способные осилить python-ng.
Прошу прощения за много букафф, всех с Новым годом :)
Спасибо автору за статью. Хотя я и пишу на нем уже лет 10, я как та домохозяйка, что не задумывается об устройстве автомобиля, она просто садиться и едет за покупками. Было интересно.
Все чаще получаю сообщение "ошибка установки защищенного соединения", особенно когда пытаюсь искать книги на разного рода файлопомойках. Подозреваю, что кроме пиара самой Mozilla эта история ни кому и ни чего больше не принесет.
Обсуждение статей, в том числе и конструктивная критика — это полезно всем. Как иначе отличить действительно полезный материал от информационного шума?
Другое дело офтоп. Я бы позволил автору статьи помечать коментарии, не связанные с темой материала, как офтоп и показывать их отдельно, а чтобы мотивировать авторов на эту работу — плюсовать им в рейт/карму. Да, возможно стоит обнулять плюсы с комментаторов, если автор отправил всю ветку в офтоп. Со спорными ситуациями администрация хабра может разобраться частным порядком.
Обсуждение статей это не общение само по себе. Это оценка статьи. Если кто — то начинает гнать офтоп, обычно, находятся желающие ему об этом напомнить.
Терзают смутные сомнения, что базовый посыл вашей статьи неверен.
Подозреваю, что хабр — это не про общение. Хабр — это про обмен качественной информацией и опытом (по крайней мере, я пришел на хабр именно за информацией). Карма оценивает качество поставляемой человеком информации, а рейт — оценивает доверие/одобрение к нему со стороны других. Одобрение со стороны авторитетного товарища, по идее, должно бы больше приносить кармы автору материала.
Это только ГИПОТЕЗА! Хотя она и объясняет существование рейтинга и кармы. Правда, если признать ее правдоподобной, то весь анализ надо начинать снова, и не забыть проанализировать, в чем создатели хабра промахнулись с реализацией, если челу можно слить карму без объяснения причин.
Любые меркантильные отношения подразумевают обязательства обеих сторон, одна — оплатить определенное количество работы, другая — ее выполнить, в срок и качественно. Чем это отличается от обычного найма, например, фрилансера?
Опять же, если добрый дядя оплатил фитчу, которую считал очень нужной, а автор не желает ее включать в пакет, как быть, если авторское право ни кто не отменял?
В общем, странная идея.
Си, как язык, абсолютно не требует подгонки подо что бы то ни было. Тем более, что и самого определения "системное программирование" в строгой и исчерпывающей форме вряд ли существует. Граница довольно сильно размыта. Например: ядро ОС безусловно системный компонент, командная оболочка csh/bash… еще, скорее всего, системная программа, утилиты, вроде find/wc уже ближе к прикладным, куда отнести KDE или XFce с гномом — это вообще тема холиварная. :)
Моя мысль была проще: если компилер может собрать самодостаточный файл, который можно запустить на голой железке, то язык, им реализуемый, можно назвать системным. И кстати, я не ограничивался одним Си. :))
Здесь ключевой момент — это способность работать без ОС. Интерпретируемые языки, даже с промежуточным представлением кода, сразу мимо. Для компилируемых — все зависит от того, можно слинковать с бинарником все зависимости или нет (сюда входит и рантайм самого языка, который, теоретически, может зависеть от наличия тех или иных библиотек и сами библиотеки, которые используются программой).
Язык Си безусловно низкоуровневый, как и всякий другой, который может создавать бинарь, способную работать на голом железе (ОС сюда входит, вместе со всеми своими компонентами в виде драйверов, модулей… ).
По поводу конфликта интересов прикладных и системных разработчиков — здесь сложно однозначно говорить, что Си тому виной. К примеру, разработчики БД стараются сами управлять взаимодействием СУБД и дискового хранилища, чтобы получить максимум скорости, но, на мой взгляд, здесь больше борьба с ОС, чем с компилятором.
По поводу памяти, кто мешает запросить у ОС кусок памяти достаточно большого размера и самому рулить его нарезкой под свои нужды? А вот следить, чтобы он не ушел в swap, больше чем нужно — это уже опять борьба с ОС, и компилятор здесь ни при чем.
Аппаратные платформы совершенствуются. Все идет в сторону параллельного и асинхронного исполнения кода. Но винить Си в отставании, на мой взгляд странно. Потоки и процессы — это не аппаратная, а программная абстракция, и так, или иначе, но именно из этого языка их реализация ушла в другие, а не наоборот.
По поводу, например, расширенных инструкций процессоров от Intel терзают смутные сомнения, что компании AMD будет позволено их реализовать в полном объеме, а значит авторам компиляторов каждый раз придется решать: работаем везде, или по максимуму, но только здесь.
По поводу стандарта, это каждый решает для себя сам. Я только недавно выучил этот язык, и просто стараюсь не использовать конструкции, работу которых не понимаю. Про сам стандарт наслышан. Как по мне, 900 страниц — это капец как много. Стоит написать его с нуля, не привязываясь к существующим реализациям и не оставляя неопределенностей. Несоответствие стандарту автоматически не делает компилятор непригодным к использованию, но может мотивировать к исправлению проблем в них. Особенно, если о них постоянно будет кто — то напоминать.
Вся история вокруг сертификатов строится исходя из того, что атакующий не может влиять на трафик и dns и, следовательно, обе стороны соединения могут обращаться к издателю сертификата как к удостоверяющему арбитру.
Федералы вроде как могут влиять на маршруты и dns.
Если они смогут завернуть процедуру выписки сертификата на себя, разве это не приведет к утечке ключей? Осталось только понять на сколько это возможно, и на сколько федералы готовы играть в долгую.
Рискну предположить, что const является семантическим правилом, работающим на этапе анализа исходного кода, и на генерацию целевого кода, скорее всего, ни как не влияющим.
Пометка значения как константа — это скорее семантическое правило "любой код, который попытается изменить это значение — неверен" чем оптимизация (хотя, возможно, какой — то из компиляторов и умеет использовать это при генерации целевого кода).
Был, а возможно и есть, такой дядька, Дэн Седенхольм, благодаря которому я познакомился с термином "пуленепробиваемый веб дизайн", сейчас этот подход похоже не особо котируется. Наверное стоит начать сожалеть об этом.
Кому интересно, может попробовать разобраться, кто у нас в стране и за что должен отвечать. Я, с момента покупки своего авто, именно этот вид транспорта предпочитаю.
Как я понимаю:
за внутренние перевозки пассажиров, в пределах одного региона, отвечают местные власти. именно они должны следить, чтобы электричек/автобусов ходило достаточно, привлекая перевозчиков и договариваясь с РЖД о сумме дотаций, там где пассажиров на нормальную загрузку не хватает.
кто отвечает за межрегиональные перевозки я, честно говоря не вкурсе.
На мой взгляд, автовокзалы не могут представлять интересы пассажиров, потому как они являются посредниками, между транспортной компанией и пассажирами и за качество оказанной услуги ответственности не несут. Общественное объединение — это вообще мутная контора, которая сама себя создала, непонятно кого защищает и чьи интересы продвигает.
Опять же, на мой взгляд, глядя на все это со стороны, ноги у этих проблем растут из за пробелов в законодательстве. Если агрегатор посредник, то я, как клиент, должен быть перенаправлен на прямой контакт с продавцом услуги, и мне абсолютно ровно, как они потом между собой выручку делят. Все вопросы с продавца. Если же, услугу мне продает агрегатор, то и все риски он должен принять на себя (и то, что техника исправна, и то что водитель в здравом уме и твердой памяти, и подготовки у него хватает).
И если мое впечатление верно, то и решать проблему надо восполнением пробелов, но ни как ни запретами, которые ущемляют интересы, прежде всего, пассажиров, потому как монополизм — это однозначно зло, для качества услуг.
Не склонен с вами согласится: ваша претензия скорее не к языкам с динамической типизацией, а к скриптовым языкам в принципе. Да, из соображений скорости проверка кода идет в 2 приема, при загрузке модуля на синтаксические ошибки, и в процессе работы на присутствие/отсутствие свойств и методов. Вы не хотите задуматься о смене языка на статически типизированный, раз со скриптами вам неудобно?
К стати, определенная работа по преодолению этих недостатков идет: например в php поддерживает тайпхинты, да и в питоне есть модуль typing с аналогичными возможностями. Правда я не знаю, на сколько эти технологии устоявшиеся, потому что, пока, проще найти код без указания типов, чем с ними.
Ок, кому — то чисто позиционные параметры нужны, я, хоть и не согласился, но понял «зачем». Чего я точно не понимаю, и вообще, слегка в шоке, «почему так»? Ну приспичило вам вам запретить обращение к параметру по имени, ну так возьмите и пометьте каждый такой параметр каким нибудь значком, или даже слово служебное придумайте. Все остальные параметры тусуем как хотим, а этот желаем видеть только на третей позиции, к примеру, и ни как иначе.
> 4.…
То, что в текущей реализации словарь оставляет значения в порядке вставки, это, скорее детали реализации, нежели дизайна языка. На мой взгляд, плохая идея — использовать эту особенность в чем — то, что будет запускаться не только вами и не один — два раза.
1. Новый оператор требует, как минимум, тщательного объяснения его применимости. Даже приведенный пример с массивом, сколько людей способно понять, почему в этом случае он не сработает? Извращенный ум и шаловливые рученки могут породить еще массу вариантов, которые нужно будет проверять, прежде чем вставлять в реальный код. И кто выиграет от такого «улучшения»?
2. Было же простое и понятное правило, сначала идут позиционные, потом именованные аргументы. Зачем и кому потребовалась эта ужесть? Зачем в список параметров функции помещать что — то кроме параметров этой самой функции?
4. Поправьте меня, если я ошибаюсь, но есть просто dict и есть OrderedDict, который помнит порядок вставки. Если для второго — ок, наверное это кому — то нужно, то для первого ценность нововведения сомнительна, на мой взгляд.
П. п. 3 и 5 особой антипатии не вызывают, хотя, лично для меня, и особой ценности не представляют.
VM питона является стековой. Для, хотя бы, эмуляции параллельного исполнения приходится каждому "параллельному процессу" предлагать "свой" стек. Если произойдет исключение и мы его не поймаем, то начнется разматывание стека виртуальной машиной, которой сугубо пофиг дым на нашу "параллельность", ей про это ничего не известно.
Моя мысль была в том, что: нельзя бесконечно курочить продукт несвойственными ему функциями, чем дальше, тем чаще это будет выходить боком. Или у вас другое мнение?
Собственно про сам язык:
От "кто виноват" перейдем к "что делать":
Прошу прощения за много букафф, всех с Новым годом :)
Спасибо автору за статью. Хотя я и пишу на нем уже лет 10, я как та домохозяйка, что не задумывается об устройстве автомобиля, она просто садиться и едет за покупками. Было интересно.
Все чаще получаю сообщение "ошибка установки защищенного соединения", особенно когда пытаюсь искать книги на разного рода файлопомойках. Подозреваю, что кроме пиара самой Mozilla эта история ни кому и ни чего больше не принесет.
Обсуждение статей, в том числе и конструктивная критика — это полезно всем. Как иначе отличить действительно полезный материал от информационного шума?
Другое дело офтоп. Я бы позволил автору статьи помечать коментарии, не связанные с темой материала, как офтоп и показывать их отдельно, а чтобы мотивировать авторов на эту работу — плюсовать им в рейт/карму. Да, возможно стоит обнулять плюсы с комментаторов, если автор отправил всю ветку в офтоп. Со спорными ситуациями администрация хабра может разобраться частным порядком.
Обсуждение статей это не общение само по себе. Это оценка статьи. Если кто — то начинает гнать офтоп, обычно, находятся желающие ему об этом напомнить.
Терзают смутные сомнения, что базовый посыл вашей статьи неверен.
Подозреваю, что хабр — это не про общение. Хабр — это про обмен качественной информацией и опытом (по крайней мере, я пришел на хабр именно за информацией). Карма оценивает качество поставляемой человеком информации, а рейт — оценивает доверие/одобрение к нему со стороны других. Одобрение со стороны авторитетного товарища, по идее, должно бы больше приносить кармы автору материала.
Это только ГИПОТЕЗА! Хотя она и объясняет существование рейтинга и кармы. Правда, если признать ее правдоподобной, то весь анализ надо начинать снова, и не забыть проанализировать, в чем создатели хабра промахнулись с реализацией, если челу можно слить карму без объяснения причин.
Любые меркантильные отношения подразумевают обязательства обеих сторон, одна — оплатить определенное количество работы, другая — ее выполнить, в срок и качественно. Чем это отличается от обычного найма, например, фрилансера?
Опять же, если добрый дядя оплатил фитчу, которую считал очень нужной, а автор не желает ее включать в пакет, как быть, если авторское право ни кто не отменял?
В общем, странная идея.
Си, как язык, абсолютно не требует подгонки подо что бы то ни было. Тем более, что и самого определения "системное программирование" в строгой и исчерпывающей форме вряд ли существует. Граница довольно сильно размыта. Например: ядро ОС безусловно системный компонент, командная оболочка csh/bash… еще, скорее всего, системная программа, утилиты, вроде find/wc уже ближе к прикладным, куда отнести KDE или XFce с гномом — это вообще тема холиварная. :)
Моя мысль была проще: если компилер может собрать самодостаточный файл, который можно запустить на голой железке, то язык, им реализуемый, можно назвать системным. И кстати, я не ограничивался одним Си. :))
Здесь ключевой момент — это способность работать без ОС. Интерпретируемые языки, даже с промежуточным представлением кода, сразу мимо. Для компилируемых — все зависит от того, можно слинковать с бинарником все зависимости или нет (сюда входит и рантайм самого языка, который, теоретически, может зависеть от наличия тех или иных библиотек и сами библиотеки, которые используются программой).
Язык Си безусловно низкоуровневый, как и всякий другой, который может создавать бинарь, способную работать на голом железе (ОС сюда входит, вместе со всеми своими компонентами в виде драйверов, модулей… ).
По поводу конфликта интересов прикладных и системных разработчиков — здесь сложно однозначно говорить, что Си тому виной. К примеру, разработчики БД стараются сами управлять взаимодействием СУБД и дискового хранилища, чтобы получить максимум скорости, но, на мой взгляд, здесь больше борьба с ОС, чем с компилятором.
По поводу памяти, кто мешает запросить у ОС кусок памяти достаточно большого размера и самому рулить его нарезкой под свои нужды? А вот следить, чтобы он не ушел в swap, больше чем нужно — это уже опять борьба с ОС, и компилятор здесь ни при чем.
Аппаратные платформы совершенствуются. Все идет в сторону параллельного и асинхронного исполнения кода. Но винить Си в отставании, на мой взгляд странно. Потоки и процессы — это не аппаратная, а программная абстракция, и так, или иначе, но именно из этого языка их реализация ушла в другие, а не наоборот.
По поводу, например, расширенных инструкций процессоров от Intel терзают смутные сомнения, что компании AMD будет позволено их реализовать в полном объеме, а значит авторам компиляторов каждый раз придется решать: работаем везде, или по максимуму, но только здесь.
По поводу стандарта, это каждый решает для себя сам. Я только недавно выучил этот язык, и просто стараюсь не использовать конструкции, работу которых не понимаю. Про сам стандарт наслышан. Как по мне, 900 страниц — это капец как много. Стоит написать его с нуля, не привязываясь к существующим реализациям и не оставляя неопределенностей. Несоответствие стандарту автоматически не делает компилятор непригодным к использованию, но может мотивировать к исправлению проблем в них. Особенно, если о них постоянно будет кто — то напоминать.
Моя мысль была такая:
Незаметнее всего было — бы попытаться прослушать процесс выписки сертификата.
Рискну предположить, что const является семантическим правилом, работающим на этапе анализа исходного кода, и на генерацию целевого кода, скорее всего, ни как не влияющим.
Пометка значения как константа — это скорее семантическое правило "любой код, который попытается изменить это значение — неверен" чем оптимизация (хотя, возможно, какой — то из компиляторов и умеет использовать это при генерации целевого кода).
Был, а возможно и есть, такой дядька, Дэн Седенхольм, благодаря которому я познакомился с термином "пуленепробиваемый веб дизайн", сейчас этот подход похоже не особо котируется. Наверное стоит начать сожалеть об этом.
Прошу прощения, не соображу, а как тогда будет выглядеть универсальная функция Sort, работающая абсолютно с любым типом, и встроенным, и кастомным?
Кому интересно, может попробовать разобраться, кто у нас в стране и за что должен отвечать. Я, с момента покупки своего авто, именно этот вид транспорта предпочитаю.
Как я понимаю:
На мой взгляд, автовокзалы не могут представлять интересы пассажиров, потому как они являются посредниками, между транспортной компанией и пассажирами и за качество оказанной услуги ответственности не несут. Общественное объединение — это вообще мутная контора, которая сама себя создала, непонятно кого защищает и чьи интересы продвигает.
Опять же, на мой взгляд, глядя на все это со стороны, ноги у этих проблем растут из за пробелов в законодательстве. Если агрегатор посредник, то я, как клиент, должен быть перенаправлен на прямой контакт с продавцом услуги, и мне абсолютно ровно, как они потом между собой выручку делят. Все вопросы с продавца. Если же, услугу мне продает агрегатор, то и все риски он должен принять на себя (и то, что техника исправна, и то что водитель в здравом уме и твердой памяти, и подготовки у него хватает).
И если мое впечатление верно, то и решать проблему надо восполнением пробелов, но ни как ни запретами, которые ущемляют интересы, прежде всего, пассажиров, потому как монополизм — это однозначно зло, для качества услуг.