Сообщение Re[12]: Питон - супер от 16.06.2018 16:27
Изменено 16.06.2018 16:30 vdimas
Re[12]: Питон - супер
Здравствуйте, netch80, Вы писали:
N>Аннотация это и есть указание типов, и в чём тебе столь принципиальная разница?
В том, что в случае Питона сама аннотация сохраняется как еще одна переменная/поле объекта, но целевое аннотируемое поле подолжает храниться и обрабатываться как бестиповое.
Но это еще не всё. Саму эту "аннотацию" можно динамически подменить.
Кароч, я бы уже не парился, а просто указывал бы типы в комментариях, так было бы всяко честнее. ))
N>Кстати, чего ты вдруг перепрыгнул на PHP, хотя перед этим субтред относился к сравнению с Matlab?
N>"Забегал" ((c) vdimas)
Я могу и по Матлабу.
Вызов нейтивных ф-ий из него или ф-ий Матлаба из нейтивной программы — как два пальца об асфальт.
Примерно так же просто, как у Пролога когда-то.
А "перепрыгнул" я раньше, будучи спровоцированным неадекватом neFormal.
N>>>И это я ещё не вспоминаю, зачем тут вообще категорически хотеть сложный рефакторинг для языка прототипирования, если в прототипе некуда те сложные методы применять.
V>>В прототипе можно и нужно не только функциональность прототипировать, но обязательно "играть" с внешним АПИ и основными сценариями.
V>>Разработка АПИ и сценариев его применения — это тоже важная часть разработки, ес-но.
N>Которые никакой рефакторинг не покроет, потому что свойства API за пределами его понимания. Подтасовываешь...
Некоторые и двух слов связать не могут и?
Был дан простой контекст — прототипирование.
Для прототипирования нужны ср-ва легкого управления кодом, т.е. рефакторинг.
V>>>>Прототипировать на ём можно только от невладения другими ср-вам прототипирования.
N>>>Которые ты, разумеется, никому не покажешь.
V>>Ну а смысл тебе показывать, бо ты не раз проявлял себя как классический хейтер того же дотнета, т.е. не раз занимал позицию отрицания ради отрицания.
N>Ну я так и понял, что аргументы ты просто не принимал, не рассматривая.
Да у вас один аргумент всегда.
Если не работает конкретно на Linux, но работает на нескольких других платформах, то это "отсутствие кроссплатформенности".
А если какая-то шняга нигде, кроме Linux, не работает, то "вот поэтому Linux лучше". (С)
Такого рода аргументы я не принимаю, разумеется.
Особенно при обсуждении прототипирования.
Я половину сознательной карьеры прототипировал для железок или встраиваемого ПО, так там принципиально прототипируешь не на том, на чём конечный продукт работает.
V>>И что характерно, что я часто прототипировал на дотнете, а целевые проекты — плюсовые для линухов.
V>>Лично меня это не смущает, я ХЗ почему смущает некоторых. ))
N>Потому что критический пласт функциональности, связанный, например, с управлением дочерними процессами, там или отсутствует
Присутствует.
N>или закрыт так, что недоступен.
Открыт целиком.
N>Причём в Core его ещё больше закрыли.
Как можно что-то закрыть в дотнете, если вызов нейтивной функциональности из него делается в одну строчку? ))
Напрямую вызывай нужную тебе ф-ию из нужной библиотеки, какие проблемы?
V>>Надо было прямо писать "он середнячок в разных дисциплинах, но в сумме набирает больше баллов".
N>Нет, не надо было. Потому что не просто "в сумме", а в адекватном сочетании элементов в удобную конструкцию.
Игра слов, попытка замылить.
V>>Итого, ключевое тут — использование одного и того же языка для всего.
V>>Последние 25+ лет я считаю такой подход ущербным.
N>Приём Pugna: приписал мне "использование для всего" и отвергаешь эту собственную приписку.
Потому что твой аргумент насчёт "по совокупности факторов" имеет значение только при тотальном широком применении языка.
А так-то в разных нишах его заруливают многие.
N>Затем отсылка к собственному авторитету — "25+ лет".
N>Смешной ты, так прямо палиться.
Дело не в авторитете, а в том, когда уже более-менее выработались и устоялись правила хорошего тона в IT как таковом, и с тех пор толком не менялись.
Вот примерно к середине 90-х годов и устаканились.
Единственная более-менее заметная коррекция приоритетов произошла как раз из-за развития ср-в рефакторинга, что раз тотальное изменение кода стало дешевым, значит ошибки архитектуры на начальном этапе перестали быть такими дорогими, поэтому приоритеты в разработке после их сортировки вышли чуть другие, с большим уклоном в мелкогранулярные итерации, т.е. бишь в agile-подход.
Но к Питону это всё не относится, бо в нём нет вменяемого рефакторинга.
В этом смысле концепция Питона сильно устарела.
V>>Питон не очень удобно сопрягать с нейтивом, в отличие от того же VB/VBA/VBS, Lua или дотнета.
V>>Поэтому, "клей" из него откровенно никудышный.
V>>Есть целая охрененейшая библиотека Boost.Python, и даже с её помощью остаётся достаточно траха.
V>>Само наличие такой либы уже много о чём говорит, что задача не из тривиальных.
N>Само наличие такой либы говорит, что потребность очень высока — выше, чем для любого другого языка.
И что при наличии такой потребности люди сами ниасиливают.
А в дотнете или матлабе — одной строчкой.
N>А оформить в библиотеку некоторые вещи — полезно для любого FFI.
Вызовы из Питона дорогие, на уровне JS.
Самые дешевые вызовы в нейтив были из VB и Лиспа/Схемы.
V>>Но закручивать гайки, всё же, лучше гаечным ключом, а не плоскогубцами.
V>>Пусть даже это очень клёвые плоскогубцы и вообще ты к ним привык как к родным.
N>Так это ты предлагаешь их закручивать напильником.
Я предлагаю применять по-назначению в том числе напильник.
А не "для всего".
Не пытайтесь приписать мне свои грехи. ))
N>>>Как ты замечательно передёрнул, вдруг заменив тему на "синтаксически" строгие языки.
V>>Ну ты же про "грабли".
N>И какая причина перейти на синтаксис? Ты других страшных слов не знаешь?
А откуда еще берутся грабли, как от несоответствия реального поведения ожидаемому?
Ожидаемое поведение расписывается через доступный в рамках языка синтаксис.
V>>В Lua и VB вообще никаких граблей прямо бай дизайн.
N>Тебе уже ответили.
Вообще-то, нет.
Даже если в том примере для Lua содержался баг, то это баг конкретной прикладной ф-ии, а не языка.
Хороший программист делает 3-5 багов за рабочий день.
Т.е., если ты хороший программист, ты ежедневно делаешь в 3-5 раз больше багов, чем содержится в той ф-ии.
Если плохой — в 10-20 раз больше.
Но это ведь не аргумент в тему обсуждения, верно?
N>Можно. Я никогда не спорил, что именно это в Питоне мне не нравится. Но простейший статический анализатор ловит подавляющее большинство случаев опечатки/etc., а остальное — тестами, потому что любая динамика их требует больше, чем статика.
Вот, подошли к сути.
Дело в том, что динамика там не нужна от слова совсем — вот в тех самых применениях, где нахваливают современный Питон.
Т.е. в языке Питон, еще раз, медленно, динамика НЕ НУЖНА.
Скриптовый язык может быть чуть ли не целиком статически типизирован абсолютно безо-всяких проблем.
Т.е. REPL, гибкость разработки, подмена кода на лету и прочее — это никак не мешает строгой типизации и строгости языкав плане переменных, как не мешает PHP, Прологу или VBA.
Так вот. "Унутре" Питон устроен очень близко к JS.
Они чуть ли не кровные братья.
У обоих очень простая модель динамического исполнения в базе: есть число, есть строка, есть функция и есть "объект", а на самом деле — просто словарик.
Текущий контекст — это тоже объект-словарик. Контексты связываются в списки. Вот и всё. Весь этот примитивизм недалеко уехал от Лиспа/Схемы, с одним большим "но" — в тех есть дополнительно макросистема с синтаксическими макросами, а в Питоне — нет. То бишь, сам язык нерасширяемый. Т.е. даже ниже Лиспа получился.
Единственный современный плюс Питона — это тонны накопленных библиотек-оберток над нейтивом.
В node.js сейчас происходит примерно то же самое. ))
N>>>Хотя я вообще ни слова про синтаксис не говорил.
V>>При чём тут ты?
N>Если ты отвечаешь на мои аргументы, то вполне при чём.
Я раскрывал, что есть "строгость". Поэтому, упоминал о синтаксисе.
Не имеет никакого значения, говорил ли ты о синтаксисе до этого.
N>Если ты споришь с собственными галлюцинациями, то зачем для этого писать ответ мне?
Это таким странным образом ты решил дать мне понять, что тебя не устраивают мои аргументы? ))
N>>>Начинаю сомневаться, что ты на Питоне вообще что-то писал больше двух страниц
V>>А надо писать больше на самом скриптовом из всех языков?
V>>Рилли? ))
N>Чтобы про него говорить с хоть сколько-то реальными аргументами — да, рилли, надо.
Не надо.
Надо изучить механику языка, его базу.
И тогда полный спектр потенциальной комбинаторики от этой базы будет сразу виден.
Это мой подход к изучению языков и Питон тут ничем не выделяется.
Да, это немного отличается от подхода некоторых, эммм, "коллег", которые могут пользоваться языком годами, написать сотни килобайт кода, но толком не понимать, что скрывается за простым, допустим, a.B = c или как происходит вызов банальной ф-ии в этом языке.
V>>Там учтены ошибки проектирования даже таких более-менее современных (в сравнении с Питоном) платформ, как дотнета.
V>>На сегодня в природе нет скриптового языка чище, во всех смыслах.
N>Покажи пару самых вкусных, по-твоему, примеров. Как обычно, твою логику предсказать нельзя, поэтому отсылка в гугл не работает.
Я уже однажды подробно перечислял, в чём Дарт переплюнул даже Дотнет.
ОК, если ко времени ответа на этот пост не потеряешь интерес, поищу тот свой пост.
N>>>>>>>Аналоги для компилируемых языков в виде мер "выгрузить целиком classloader или assembly, сериализовав состояние" не дают плавный незаметный переход.
V>>Между второй и последней строчкой можно "на лету" заменить бинарник COM-объекта.
N>То есть ты снова не читаешь задачу.
Да не было "задачи", чего ты так возбудился?
Ты привёл как аргумент "подмена кода на лету", а я лишь подколол, что это можно даже на нейтиве.
N>>>Иначе сложно объяснить, почему ты даже в моём укороченном описании пропустил всё, кроме упоминания выгрузки.
V>>Я не пропустил, я как раз показал, что "горячая замена кода" легко делается даже на нейтиве, т.е. не аргумент ни в одном из мест.
N>"Легко" она как раз не делается.
Тем не менее, настаиваю.
Эта функциональность зашита прямо в базовый класс объекта VB, ATL или OLE-объекта, реализованного на MFC.
Т.е. эта функциональность дана сверху "по умолчанию".
Ну, т.е., если не писать COM-объекты вообще с 0-ля ручками, то всё это данность.
(а писать их ручками с 0-ля — примерно той же полезности задача, как писать на дотнете свой класс строки)
V>>Потому что я верил, что ты, скорее всего, хотя бы краем уха слышал о такой функциональности, просто забыл в пылу спора — иначе бы не потребовал ссылок.
V>>Но ты потребовал ссылки, чем и спалился, собсно. Вот я тебе и намекнул. ))
N>Спалился ты — на нечтении задачи. Опять невидимые собеседники чего-то намешали, видимо...
Какие мы обидчивые, однако...
N>Аннотация это и есть указание типов, и в чём тебе столь принципиальная разница?
В том, что в случае Питона сама аннотация сохраняется как еще одна переменная/поле объекта, но целевое аннотируемое поле подолжает храниться и обрабатываться как бестиповое.
Но это еще не всё. Саму эту "аннотацию" можно динамически подменить.
Кароч, я бы уже не парился, а просто указывал бы типы в комментариях, так было бы всяко честнее. ))
N>Кстати, чего ты вдруг перепрыгнул на PHP, хотя перед этим субтред относился к сравнению с Matlab?
N>"Забегал" ((c) vdimas)
Я могу и по Матлабу.
Вызов нейтивных ф-ий из него или ф-ий Матлаба из нейтивной программы — как два пальца об асфальт.
Примерно так же просто, как у Пролога когда-то.
А "перепрыгнул" я раньше, будучи спровоцированным неадекватом neFormal.
N>>>И это я ещё не вспоминаю, зачем тут вообще категорически хотеть сложный рефакторинг для языка прототипирования, если в прототипе некуда те сложные методы применять.
V>>В прототипе можно и нужно не только функциональность прототипировать, но обязательно "играть" с внешним АПИ и основными сценариями.
V>>Разработка АПИ и сценариев его применения — это тоже важная часть разработки, ес-но.
N>Которые никакой рефакторинг не покроет, потому что свойства API за пределами его понимания. Подтасовываешь...
Некоторые и двух слов связать не могут и?
Был дан простой контекст — прототипирование.
Для прототипирования нужны ср-ва легкого управления кодом, т.е. рефакторинг.
V>>>>Прототипировать на ём можно только от невладения другими ср-вам прототипирования.
N>>>Которые ты, разумеется, никому не покажешь.
V>>Ну а смысл тебе показывать, бо ты не раз проявлял себя как классический хейтер того же дотнета, т.е. не раз занимал позицию отрицания ради отрицания.
N>Ну я так и понял, что аргументы ты просто не принимал, не рассматривая.
Да у вас один аргумент всегда.
Если не работает конкретно на Linux, но работает на нескольких других платформах, то это "отсутствие кроссплатформенности".
А если какая-то шняга нигде, кроме Linux, не работает, то "вот поэтому Linux лучше". (С)
Такого рода аргументы я не принимаю, разумеется.
Особенно при обсуждении прототипирования.
Я половину сознательной карьеры прототипировал для железок или встраиваемого ПО, так там принципиально прототипируешь не на том, на чём конечный продукт работает.
V>>И что характерно, что я часто прототипировал на дотнете, а целевые проекты — плюсовые для линухов.
V>>Лично меня это не смущает, я ХЗ почему смущает некоторых. ))
N>Потому что критический пласт функциональности, связанный, например, с управлением дочерними процессами, там или отсутствует
Присутствует.
N>или закрыт так, что недоступен.
Открыт целиком.
N>Причём в Core его ещё больше закрыли.
Как можно что-то закрыть в дотнете, если вызов нейтивной функциональности из него делается в одну строчку? ))
Напрямую вызывай нужную тебе ф-ию из нужной библиотеки, какие проблемы?
V>>Надо было прямо писать "он середнячок в разных дисциплинах, но в сумме набирает больше баллов".
N>Нет, не надо было. Потому что не просто "в сумме", а в адекватном сочетании элементов в удобную конструкцию.
Игра слов, попытка замылить.
V>>Итого, ключевое тут — использование одного и того же языка для всего.
V>>Последние 25+ лет я считаю такой подход ущербным.
N>Приём Pugna: приписал мне "использование для всего" и отвергаешь эту собственную приписку.
Потому что твой аргумент насчёт "по совокупности факторов" имеет значение только при тотальном широком применении языка.
А так-то в разных нишах его заруливают многие.
N>Затем отсылка к собственному авторитету — "25+ лет".
N>Смешной ты, так прямо палиться.
Дело не в авторитете, а в том, когда уже более-менее выработались и устоялись правила хорошего тона в IT как таковом, и с тех пор толком не менялись.
Вот примерно к середине 90-х годов и устаканились.
Единственная более-менее заметная коррекция приоритетов произошла как раз из-за развития ср-в рефакторинга, что раз тотальное изменение кода стало дешевым, значит ошибки архитектуры на начальном этапе перестали быть такими дорогими, поэтому приоритеты в разработке после их сортировки вышли чуть другие, с большим уклоном в мелкогранулярные итерации, т.е. бишь в agile-подход.
Но к Питону это всё не относится, бо в нём нет вменяемого рефакторинга.
В этом смысле концепция Питона сильно устарела.
V>>Питон не очень удобно сопрягать с нейтивом, в отличие от того же VB/VBA/VBS, Lua или дотнета.
V>>Поэтому, "клей" из него откровенно никудышный.
V>>Есть целая охрененейшая библиотека Boost.Python, и даже с её помощью остаётся достаточно траха.
V>>Само наличие такой либы уже много о чём говорит, что задача не из тривиальных.
N>Само наличие такой либы говорит, что потребность очень высока — выше, чем для любого другого языка.
И что при наличии такой потребности люди сами ниасиливают.
А в дотнете или матлабе — одной строчкой.
N>А оформить в библиотеку некоторые вещи — полезно для любого FFI.
Вызовы из Питона дорогие, на уровне JS.
Самые дешевые вызовы в нейтив были из VB и Лиспа/Схемы.
V>>Но закручивать гайки, всё же, лучше гаечным ключом, а не плоскогубцами.
V>>Пусть даже это очень клёвые плоскогубцы и вообще ты к ним привык как к родным.
N>Так это ты предлагаешь их закручивать напильником.
Я предлагаю применять по-назначению в том числе напильник.
А не "для всего".
Не пытайтесь приписать мне свои грехи. ))
N>>>Как ты замечательно передёрнул, вдруг заменив тему на "синтаксически" строгие языки.
V>>Ну ты же про "грабли".
N>И какая причина перейти на синтаксис? Ты других страшных слов не знаешь?
А откуда еще берутся грабли, как от несоответствия реального поведения ожидаемому?
Ожидаемое поведение расписывается через доступный в рамках языка синтаксис.
V>>В Lua и VB вообще никаких граблей прямо бай дизайн.
N>Тебе уже ответили.
Вообще-то, нет.
Даже если в том примере для Lua содержался баг, то это баг конкретной прикладной ф-ии, а не языка.
Хороший программист делает 3-5 багов за рабочий день.
Т.е., если ты хороший программист, ты ежедневно делаешь в 3-5 раз больше багов, чем содержится в той ф-ии.
Если плохой — в 10-20 раз больше.
Но это ведь не аргумент в тему обсуждения, верно?
N>Можно. Я никогда не спорил, что именно это в Питоне мне не нравится. Но простейший статический анализатор ловит подавляющее большинство случаев опечатки/etc., а остальное — тестами, потому что любая динамика их требует больше, чем статика.
Вот, подошли к сути.
Дело в том, что динамика там не нужна от слова совсем — вот в тех самых применениях, где нахваливают современный Питон.
Т.е. в языке Питон, еще раз, медленно, динамика НЕ НУЖНА.
Скриптовый язык может быть чуть ли не целиком статически типизирован абсолютно безо-всяких проблем.
Т.е. REPL, гибкость разработки, подмена кода на лету и прочее — это никак не мешает строгой типизации и строгости языкав плане переменных, как не мешает PHP, Прологу или VBA.
Так вот. "Унутре" Питон устроен очень близко к JS.
Они чуть ли не кровные братья.
У обоих очень простая модель динамического исполнения в базе: есть число, есть строка, есть функция и есть "объект", а на самом деле — просто словарик.
Текущий контекст — это тоже объект-словарик. Контексты связываются в списки. Вот и всё. Весь этот примитивизм недалеко уехал от Лиспа/Схемы, с одним большим "но" — в тех есть дополнительно макросистема с синтаксическими макросами, а в Питоне — нет. То бишь, сам язык нерасширяемый. Т.е. даже ниже Лиспа получился.
Единственный современный плюс Питона — это тонны накопленных библиотек-оберток над нейтивом.
В node.js сейчас происходит примерно то же самое. ))
N>>>Хотя я вообще ни слова про синтаксис не говорил.
V>>При чём тут ты?
N>Если ты отвечаешь на мои аргументы, то вполне при чём.
Я раскрывал, что есть "строгость". Поэтому, упоминал о синтаксисе.
Не имеет никакого значения, говорил ли ты о синтаксисе до этого.
N>Если ты споришь с собственными галлюцинациями, то зачем для этого писать ответ мне?
Это таким странным образом ты решил дать мне понять, что тебя не устраивают мои аргументы? ))
N>>>Начинаю сомневаться, что ты на Питоне вообще что-то писал больше двух страниц
V>>А надо писать больше на самом скриптовом из всех языков?
V>>Рилли? ))
N>Чтобы про него говорить с хоть сколько-то реальными аргументами — да, рилли, надо.
Не надо.
Надо изучить механику языка, его базу.
И тогда полный спектр потенциальной комбинаторики от этой базы будет сразу виден.
Это мой подход к изучению языков и Питон тут ничем не выделяется.
Да, это немного отличается от подхода некоторых, эммм, "коллег", которые могут пользоваться языком годами, написать сотни килобайт кода, но толком не понимать, что скрывается за простым, допустим, a.B = c или как происходит вызов банальной ф-ии в этом языке.
V>>Там учтены ошибки проектирования даже таких более-менее современных (в сравнении с Питоном) платформ, как дотнета.
V>>На сегодня в природе нет скриптового языка чище, во всех смыслах.
N>Покажи пару самых вкусных, по-твоему, примеров. Как обычно, твою логику предсказать нельзя, поэтому отсылка в гугл не работает.
Я уже однажды подробно перечислял, в чём Дарт переплюнул даже Дотнет.
ОК, если ко времени ответа на этот пост не потеряешь интерес, поищу тот свой пост.
N>>>>>>>Аналоги для компилируемых языков в виде мер "выгрузить целиком classloader или assembly, сериализовав состояние" не дают плавный незаметный переход.
V>>Между второй и последней строчкой можно "на лету" заменить бинарник COM-объекта.
N>То есть ты снова не читаешь задачу.
Да не было "задачи", чего ты так возбудился?
Ты привёл как аргумент "подмена кода на лету", а я лишь подколол, что это можно даже на нейтиве.
N>>>Иначе сложно объяснить, почему ты даже в моём укороченном описании пропустил всё, кроме упоминания выгрузки.
V>>Я не пропустил, я как раз показал, что "горячая замена кода" легко делается даже на нейтиве, т.е. не аргумент ни в одном из мест.
N>"Легко" она как раз не делается.
Тем не менее, настаиваю.
Эта функциональность зашита прямо в базовый класс объекта VB, ATL или OLE-объекта, реализованного на MFC.
Т.е. эта функциональность дана сверху "по умолчанию".
Ну, т.е., если не писать COM-объекты вообще с 0-ля ручками, то всё это данность.
(а писать их ручками с 0-ля — примерно той же полезности задача, как писать на дотнете свой класс строки)
V>>Потому что я верил, что ты, скорее всего, хотя бы краем уха слышал о такой функциональности, просто забыл в пылу спора — иначе бы не потребовал ссылок.
V>>Но ты потребовал ссылки, чем и спалился, собсно. Вот я тебе и намекнул. ))
N>Спалился ты — на нечтении задачи. Опять невидимые собеседники чего-то намешали, видимо...
Какие мы обидчивые, однако...
Re[12]: Питон - супер
Здравствуйте, netch80, Вы писали:
N>Аннотация это и есть указание типов, и в чём тебе столь принципиальная разница?
В том, что в случае Питона сама аннотация сохраняется как еще одна переменная/поле объекта, но целевое аннотируемое поле подолжает храниться и обрабатываться как бестиповое.
Но это еще не всё. Саму эту "аннотацию" можно динамически подменить.
Кароч, я бы уже не парился, а просто указывал бы типы в комментариях, так было бы всяко честнее. ))
N>Кстати, чего ты вдруг перепрыгнул на PHP, хотя перед этим субтред относился к сравнению с Matlab?
N>"Забегал" ((c) vdimas)
Я могу и по Матлабу.
Вызов нейтивных ф-ий из него или ф-ий Матлаба из нейтивной программы — как два пальца об асфальт.
Примерно так же просто, как у Пролога когда-то.
А "перепрыгнул" я раньше, будучи спровоцированным неадекватом neFormal.
N>>>И это я ещё не вспоминаю, зачем тут вообще категорически хотеть сложный рефакторинг для языка прототипирования, если в прототипе некуда те сложные методы применять.
V>>В прототипе можно и нужно не только функциональность прототипировать, но обязательно "играть" с внешним АПИ и основными сценариями.
V>>Разработка АПИ и сценариев его применения — это тоже важная часть разработки, ес-но.
N>Которые никакой рефакторинг не покроет, потому что свойства API за пределами его понимания. Подтасовываешь...
Некоторые и двух слов связать не могут и?
Был дан простой контекст — прототипирование.
Для прототипирования нужны ср-ва легкого управления кодом, т.е. рефакторинг.
V>>>>Прототипировать на ём можно только от невладения другими ср-вам прототипирования.
N>>>Которые ты, разумеется, никому не покажешь.
V>>Ну а смысл тебе показывать, бо ты не раз проявлял себя как классический хейтер того же дотнета, т.е. не раз занимал позицию отрицания ради отрицания.
N>Ну я так и понял, что аргументы ты просто не принимал, не рассматривая.
Да у вас один аргумент всегда.
Если не работает конкретно на Linux, но работает на нескольких других платформах, то это "отсутствие кроссплатформенности".
А если какая-то шняга нигде, кроме Linux, не работает, то "вот поэтому Linux лучше". (С)
Такого рода аргументы я не принимаю, разумеется.
Особенно при обсуждении прототипирования.
Я половину сознательной карьеры прототипировал для железок или встраиваемого ПО, так там принципиально прототипируешь не на том, на чём конечный продукт работает.
V>>И что характерно, что я часто прототипировал на дотнете, а целевые проекты — плюсовые для линухов.
V>>Лично меня это не смущает, я ХЗ почему смущает некоторых. ))
N>Потому что критический пласт функциональности, связанный, например, с управлением дочерними процессами, там или отсутствует
Присутствует.
N>или закрыт так, что недоступен.
Открыт целиком.
N>Причём в Core его ещё больше закрыли.
Как можно что-то закрыть в дотнете, если вызов нейтивной функциональности из него делается в одну строчку? ))
Напрямую вызывай нужную тебе ф-ию из нужной библиотеки, какие проблемы?
V>>Надо было прямо писать "он середнячок в разных дисциплинах, но в сумме набирает больше баллов".
N>Нет, не надо было. Потому что не просто "в сумме", а в адекватном сочетании элементов в удобную конструкцию.
Игра слов, попытка замылить.
V>>Итого, ключевое тут — использование одного и того же языка для всего.
V>>Последние 25+ лет я считаю такой подход ущербным.
N>Приём Pugna: приписал мне "использование для всего" и отвергаешь эту собственную приписку.
Потому что твой аргумент насчёт "по совокупности факторов" имеет значение только при тотальном широком применении языка.
А так-то в разных нишах его заруливают многие.
N>Затем отсылка к собственному авторитету — "25+ лет".
N>Смешной ты, так прямо палиться.
Дело не в авторитете, а в том, когда (как давно) уже более-менее выработались и устоялись правила хорошего тона в IT как таковом, и с тех пор толком не менялись.
Вот примерно к середине 90-х годов и устаканились.
Единственная более-менее заметная коррекция приоритетов произошла как раз из-за развития ср-в рефакторинга, что раз тотальное изменение кода стало дешевым, значит ошибки архитектуры на начальном этапе перестали быть такими дорогими, поэтому приоритеты в разработке после их сортировки вышли чуть другие, с большим уклоном в мелкогранулярные итерации, т.е. бишь в agile-подход.
Но к Питону это всё не относится, бо в нём нет вменяемого рефакторинга.
В этом смысле концепция Питона сильно устарела.
V>>Питон не очень удобно сопрягать с нейтивом, в отличие от того же VB/VBA/VBS, Lua или дотнета.
V>>Поэтому, "клей" из него откровенно никудышный.
V>>Есть целая охрененейшая библиотека Boost.Python, и даже с её помощью остаётся достаточно траха.
V>>Само наличие такой либы уже много о чём говорит, что задача не из тривиальных.
N>Само наличие такой либы говорит, что потребность очень высока — выше, чем для любого другого языка.
И что при наличии такой потребности люди сами ниасиливают.
А в дотнете или матлабе — одной строчкой.
N>А оформить в библиотеку некоторые вещи — полезно для любого FFI.
Вызовы из Питона дорогие, на уровне JS.
Самые дешевые вызовы в нейтив были из VB и Лиспа/Схемы.
V>>Но закручивать гайки, всё же, лучше гаечным ключом, а не плоскогубцами.
V>>Пусть даже это очень клёвые плоскогубцы и вообще ты к ним привык как к родным.
N>Так это ты предлагаешь их закручивать напильником.
Я предлагаю применять по-назначению в том числе напильник.
А не "для всего".
Не пытайтесь приписать мне свои грехи. ))
N>>>Как ты замечательно передёрнул, вдруг заменив тему на "синтаксически" строгие языки.
V>>Ну ты же про "грабли".
N>И какая причина перейти на синтаксис? Ты других страшных слов не знаешь?
А откуда еще берутся грабли, как от несоответствия реального поведения ожидаемому?
Ожидаемое поведение расписывается через доступный в рамках языка синтаксис.
V>>В Lua и VB вообще никаких граблей прямо бай дизайн.
N>Тебе уже ответили.
Вообще-то, нет.
Даже если в том примере для Lua содержался баг, то это баг конкретной прикладной ф-ии, а не языка.
Хороший программист делает 3-5 багов за рабочий день.
Т.е., если ты хороший программист, ты ежедневно делаешь в 3-5 раз больше багов, чем содержится в той ф-ии.
Если плохой — в 10-20 раз больше.
Но это ведь не аргумент в тему обсуждения, верно?
N>Можно. Я никогда не спорил, что именно это в Питоне мне не нравится. Но простейший статический анализатор ловит подавляющее большинство случаев опечатки/etc., а остальное — тестами, потому что любая динамика их требует больше, чем статика.
Вот, подошли к сути.
Дело в том, что динамика там не нужна от слова совсем — вот в тех самых применениях, где нахваливают современный Питон.
Т.е. в языке Питон, еще раз, медленно, динамика НЕ НУЖНА.
Скриптовый язык может быть чуть ли не целиком статически типизирован абсолютно безо-всяких проблем.
Т.е. REPL, гибкость разработки, подмена кода на лету и прочее — это никак не мешает строгой типизации и строгости языкав плане переменных, как не мешает PHP, Прологу или VBA.
Так вот. "Унутре" Питон устроен очень близко к JS.
Они чуть ли не кровные братья.
У обоих очень простая модель динамического исполнения в базе: есть число, есть строка, есть функция и есть "объект", а на самом деле — просто словарик.
Текущий контекст — это тоже объект-словарик. Контексты связываются в списки. Вот и всё. Весь этот примитивизм недалеко уехал от Лиспа/Схемы, с одним большим "но" — в тех есть дополнительно макросистема с синтаксическими макросами, а в Питоне — нет. То бишь, сам язык нерасширяемый. Т.е. даже ниже Лиспа получился.
Единственный современный плюс Питона — это тонны накопленных библиотек-оберток над нейтивом.
В node.js сейчас происходит примерно то же самое. ))
N>>>Хотя я вообще ни слова про синтаксис не говорил.
V>>При чём тут ты?
N>Если ты отвечаешь на мои аргументы, то вполне при чём.
Я раскрывал, что есть "строгость". Поэтому, упоминал о синтаксисе.
Не имеет никакого значения, говорил ли ты о синтаксисе до этого.
N>Если ты споришь с собственными галлюцинациями, то зачем для этого писать ответ мне?
Это таким странным образом ты решил дать мне понять, что тебя не устраивают мои аргументы? ))
N>>>Начинаю сомневаться, что ты на Питоне вообще что-то писал больше двух страниц
V>>А надо писать больше на самом скриптовом из всех языков?
V>>Рилли? ))
N>Чтобы про него говорить с хоть сколько-то реальными аргументами — да, рилли, надо.
Не надо.
Надо изучить механику языка, его базу.
И тогда полный спектр потенциальной комбинаторики от этой базы будет сразу виден.
Это мой подход к изучению языков и Питон тут ничем не выделяется.
Да, это немного отличается от подхода некоторых, эммм, "коллег", которые могут пользоваться языком годами, написать сотни килобайт кода, но толком не понимать, что скрывается за простым, допустим, a.B = c или как происходит вызов банальной ф-ии в этом языке.
V>>Там учтены ошибки проектирования даже таких более-менее современных (в сравнении с Питоном) платформ, как дотнета.
V>>На сегодня в природе нет скриптового языка чище, во всех смыслах.
N>Покажи пару самых вкусных, по-твоему, примеров. Как обычно, твою логику предсказать нельзя, поэтому отсылка в гугл не работает.
Я уже однажды подробно перечислял, в чём Дарт переплюнул даже Дотнет.
ОК, если ко времени ответа на этот пост не потеряешь интерес, поищу тот свой пост.
N>>>>>>>Аналоги для компилируемых языков в виде мер "выгрузить целиком classloader или assembly, сериализовав состояние" не дают плавный незаметный переход.
V>>Между второй и последней строчкой можно "на лету" заменить бинарник COM-объекта.
N>То есть ты снова не читаешь задачу.
Да не было "задачи", чего ты так возбудился?
Ты привёл как аргумент "подмена кода на лету", а я лишь подколол, что это можно даже на нейтиве.
N>>>Иначе сложно объяснить, почему ты даже в моём укороченном описании пропустил всё, кроме упоминания выгрузки.
V>>Я не пропустил, я как раз показал, что "горячая замена кода" легко делается даже на нейтиве, т.е. не аргумент ни в одном из мест.
N>"Легко" она как раз не делается.
Тем не менее, настаиваю.
Эта функциональность зашита прямо в базовый класс объекта VB, ATL или OLE-объекта, реализованного на MFC.
Т.е. эта функциональность дана сверху "по умолчанию".
Ну, т.е., если не писать COM-объекты вообще с 0-ля ручками, то всё это данность.
(а писать их ручками с 0-ля — примерно той же полезности задача, как писать на дотнете свой класс строки)
V>>Потому что я верил, что ты, скорее всего, хотя бы краем уха слышал о такой функциональности, просто забыл в пылу спора — иначе бы не потребовал ссылок.
V>>Но ты потребовал ссылки, чем и спалился, собсно. Вот я тебе и намекнул. ))
N>Спалился ты — на нечтении задачи. Опять невидимые собеседники чего-то намешали, видимо...
Какие мы обидчивые, однако...
N>Аннотация это и есть указание типов, и в чём тебе столь принципиальная разница?
В том, что в случае Питона сама аннотация сохраняется как еще одна переменная/поле объекта, но целевое аннотируемое поле подолжает храниться и обрабатываться как бестиповое.
Но это еще не всё. Саму эту "аннотацию" можно динамически подменить.
Кароч, я бы уже не парился, а просто указывал бы типы в комментариях, так было бы всяко честнее. ))
N>Кстати, чего ты вдруг перепрыгнул на PHP, хотя перед этим субтред относился к сравнению с Matlab?
N>"Забегал" ((c) vdimas)
Я могу и по Матлабу.
Вызов нейтивных ф-ий из него или ф-ий Матлаба из нейтивной программы — как два пальца об асфальт.
Примерно так же просто, как у Пролога когда-то.
А "перепрыгнул" я раньше, будучи спровоцированным неадекватом neFormal.
N>>>И это я ещё не вспоминаю, зачем тут вообще категорически хотеть сложный рефакторинг для языка прототипирования, если в прототипе некуда те сложные методы применять.
V>>В прототипе можно и нужно не только функциональность прототипировать, но обязательно "играть" с внешним АПИ и основными сценариями.
V>>Разработка АПИ и сценариев его применения — это тоже важная часть разработки, ес-но.
N>Которые никакой рефакторинг не покроет, потому что свойства API за пределами его понимания. Подтасовываешь...
Некоторые и двух слов связать не могут и?
Был дан простой контекст — прототипирование.
Для прототипирования нужны ср-ва легкого управления кодом, т.е. рефакторинг.
V>>>>Прототипировать на ём можно только от невладения другими ср-вам прототипирования.
N>>>Которые ты, разумеется, никому не покажешь.
V>>Ну а смысл тебе показывать, бо ты не раз проявлял себя как классический хейтер того же дотнета, т.е. не раз занимал позицию отрицания ради отрицания.
N>Ну я так и понял, что аргументы ты просто не принимал, не рассматривая.
Да у вас один аргумент всегда.
Если не работает конкретно на Linux, но работает на нескольких других платформах, то это "отсутствие кроссплатформенности".
А если какая-то шняга нигде, кроме Linux, не работает, то "вот поэтому Linux лучше". (С)
Такого рода аргументы я не принимаю, разумеется.
Особенно при обсуждении прототипирования.
Я половину сознательной карьеры прототипировал для железок или встраиваемого ПО, так там принципиально прототипируешь не на том, на чём конечный продукт работает.
V>>И что характерно, что я часто прототипировал на дотнете, а целевые проекты — плюсовые для линухов.
V>>Лично меня это не смущает, я ХЗ почему смущает некоторых. ))
N>Потому что критический пласт функциональности, связанный, например, с управлением дочерними процессами, там или отсутствует
Присутствует.
N>или закрыт так, что недоступен.
Открыт целиком.
N>Причём в Core его ещё больше закрыли.
Как можно что-то закрыть в дотнете, если вызов нейтивной функциональности из него делается в одну строчку? ))
Напрямую вызывай нужную тебе ф-ию из нужной библиотеки, какие проблемы?
V>>Надо было прямо писать "он середнячок в разных дисциплинах, но в сумме набирает больше баллов".
N>Нет, не надо было. Потому что не просто "в сумме", а в адекватном сочетании элементов в удобную конструкцию.
Игра слов, попытка замылить.
V>>Итого, ключевое тут — использование одного и того же языка для всего.
V>>Последние 25+ лет я считаю такой подход ущербным.
N>Приём Pugna: приписал мне "использование для всего" и отвергаешь эту собственную приписку.
Потому что твой аргумент насчёт "по совокупности факторов" имеет значение только при тотальном широком применении языка.
А так-то в разных нишах его заруливают многие.
N>Затем отсылка к собственному авторитету — "25+ лет".
N>Смешной ты, так прямо палиться.
Дело не в авторитете, а в том, когда (как давно) уже более-менее выработались и устоялись правила хорошего тона в IT как таковом, и с тех пор толком не менялись.
Вот примерно к середине 90-х годов и устаканились.
Единственная более-менее заметная коррекция приоритетов произошла как раз из-за развития ср-в рефакторинга, что раз тотальное изменение кода стало дешевым, значит ошибки архитектуры на начальном этапе перестали быть такими дорогими, поэтому приоритеты в разработке после их сортировки вышли чуть другие, с большим уклоном в мелкогранулярные итерации, т.е. бишь в agile-подход.
Но к Питону это всё не относится, бо в нём нет вменяемого рефакторинга.
В этом смысле концепция Питона сильно устарела.
V>>Питон не очень удобно сопрягать с нейтивом, в отличие от того же VB/VBA/VBS, Lua или дотнета.
V>>Поэтому, "клей" из него откровенно никудышный.
V>>Есть целая охрененейшая библиотека Boost.Python, и даже с её помощью остаётся достаточно траха.
V>>Само наличие такой либы уже много о чём говорит, что задача не из тривиальных.
N>Само наличие такой либы говорит, что потребность очень высока — выше, чем для любого другого языка.
И что при наличии такой потребности люди сами ниасиливают.
А в дотнете или матлабе — одной строчкой.
N>А оформить в библиотеку некоторые вещи — полезно для любого FFI.
Вызовы из Питона дорогие, на уровне JS.
Самые дешевые вызовы в нейтив были из VB и Лиспа/Схемы.
V>>Но закручивать гайки, всё же, лучше гаечным ключом, а не плоскогубцами.
V>>Пусть даже это очень клёвые плоскогубцы и вообще ты к ним привык как к родным.
N>Так это ты предлагаешь их закручивать напильником.
Я предлагаю применять по-назначению в том числе напильник.
А не "для всего".
Не пытайтесь приписать мне свои грехи. ))
N>>>Как ты замечательно передёрнул, вдруг заменив тему на "синтаксически" строгие языки.
V>>Ну ты же про "грабли".
N>И какая причина перейти на синтаксис? Ты других страшных слов не знаешь?
А откуда еще берутся грабли, как от несоответствия реального поведения ожидаемому?
Ожидаемое поведение расписывается через доступный в рамках языка синтаксис.
V>>В Lua и VB вообще никаких граблей прямо бай дизайн.
N>Тебе уже ответили.
Вообще-то, нет.
Даже если в том примере для Lua содержался баг, то это баг конкретной прикладной ф-ии, а не языка.
Хороший программист делает 3-5 багов за рабочий день.
Т.е., если ты хороший программист, ты ежедневно делаешь в 3-5 раз больше багов, чем содержится в той ф-ии.
Если плохой — в 10-20 раз больше.
Но это ведь не аргумент в тему обсуждения, верно?
N>Можно. Я никогда не спорил, что именно это в Питоне мне не нравится. Но простейший статический анализатор ловит подавляющее большинство случаев опечатки/etc., а остальное — тестами, потому что любая динамика их требует больше, чем статика.
Вот, подошли к сути.
Дело в том, что динамика там не нужна от слова совсем — вот в тех самых применениях, где нахваливают современный Питон.
Т.е. в языке Питон, еще раз, медленно, динамика НЕ НУЖНА.
Скриптовый язык может быть чуть ли не целиком статически типизирован абсолютно безо-всяких проблем.
Т.е. REPL, гибкость разработки, подмена кода на лету и прочее — это никак не мешает строгой типизации и строгости языкав плане переменных, как не мешает PHP, Прологу или VBA.
Так вот. "Унутре" Питон устроен очень близко к JS.
Они чуть ли не кровные братья.
У обоих очень простая модель динамического исполнения в базе: есть число, есть строка, есть функция и есть "объект", а на самом деле — просто словарик.
Текущий контекст — это тоже объект-словарик. Контексты связываются в списки. Вот и всё. Весь этот примитивизм недалеко уехал от Лиспа/Схемы, с одним большим "но" — в тех есть дополнительно макросистема с синтаксическими макросами, а в Питоне — нет. То бишь, сам язык нерасширяемый. Т.е. даже ниже Лиспа получился.
Единственный современный плюс Питона — это тонны накопленных библиотек-оберток над нейтивом.
В node.js сейчас происходит примерно то же самое. ))
N>>>Хотя я вообще ни слова про синтаксис не говорил.
V>>При чём тут ты?
N>Если ты отвечаешь на мои аргументы, то вполне при чём.
Я раскрывал, что есть "строгость". Поэтому, упоминал о синтаксисе.
Не имеет никакого значения, говорил ли ты о синтаксисе до этого.
N>Если ты споришь с собственными галлюцинациями, то зачем для этого писать ответ мне?
Это таким странным образом ты решил дать мне понять, что тебя не устраивают мои аргументы? ))
N>>>Начинаю сомневаться, что ты на Питоне вообще что-то писал больше двух страниц
V>>А надо писать больше на самом скриптовом из всех языков?
V>>Рилли? ))
N>Чтобы про него говорить с хоть сколько-то реальными аргументами — да, рилли, надо.
Не надо.
Надо изучить механику языка, его базу.
И тогда полный спектр потенциальной комбинаторики от этой базы будет сразу виден.
Это мой подход к изучению языков и Питон тут ничем не выделяется.
Да, это немного отличается от подхода некоторых, эммм, "коллег", которые могут пользоваться языком годами, написать сотни килобайт кода, но толком не понимать, что скрывается за простым, допустим, a.B = c или как происходит вызов банальной ф-ии в этом языке.
V>>Там учтены ошибки проектирования даже таких более-менее современных (в сравнении с Питоном) платформ, как дотнета.
V>>На сегодня в природе нет скриптового языка чище, во всех смыслах.
N>Покажи пару самых вкусных, по-твоему, примеров. Как обычно, твою логику предсказать нельзя, поэтому отсылка в гугл не работает.
Я уже однажды подробно перечислял, в чём Дарт переплюнул даже Дотнет.
ОК, если ко времени ответа на этот пост не потеряешь интерес, поищу тот свой пост.
N>>>>>>>Аналоги для компилируемых языков в виде мер "выгрузить целиком classloader или assembly, сериализовав состояние" не дают плавный незаметный переход.
V>>Между второй и последней строчкой можно "на лету" заменить бинарник COM-объекта.
N>То есть ты снова не читаешь задачу.
Да не было "задачи", чего ты так возбудился?
Ты привёл как аргумент "подмена кода на лету", а я лишь подколол, что это можно даже на нейтиве.
N>>>Иначе сложно объяснить, почему ты даже в моём укороченном описании пропустил всё, кроме упоминания выгрузки.
V>>Я не пропустил, я как раз показал, что "горячая замена кода" легко делается даже на нейтиве, т.е. не аргумент ни в одном из мест.
N>"Легко" она как раз не делается.
Тем не менее, настаиваю.
Эта функциональность зашита прямо в базовый класс объекта VB, ATL или OLE-объекта, реализованного на MFC.
Т.е. эта функциональность дана сверху "по умолчанию".
Ну, т.е., если не писать COM-объекты вообще с 0-ля ручками, то всё это данность.
(а писать их ручками с 0-ля — примерно той же полезности задача, как писать на дотнете свой класс строки)
V>>Потому что я верил, что ты, скорее всего, хотя бы краем уха слышал о такой функциональности, просто забыл в пылу спора — иначе бы не потребовал ссылок.
V>>Но ты потребовал ссылки, чем и спалился, собсно. Вот я тебе и намекнул. ))
N>Спалился ты — на нечтении задачи. Опять невидимые собеседники чего-то намешали, видимо...
Какие мы обидчивые, однако...