Здравствуйте, netch80, Вы писали:
V>>>>>>А так-то сам по себе PHP очень даже неплох, местами на голову выше Питона, разумеется. N>>>Начни с обоснования этого тезиса, безаргументный ты наш... V>>- Меньше неявных соглашений. N>Безаргументно.
Нет, это важный аргумент. Один из самых важных.
В Питоне до черта неявных соглашений:
— по синтаксису;
— по правилам именования идентификаторов;
— по огромному количеству "системных" ф-ий и методов, полный список которых перевешивает вдвое запас ключевых слов многих сравнимых по функциональности языков.
А есть же еще и ключевые слова сверху. ))
N>С учётом следующего пункта — их больше.
Не увидел раскрытия мысли.
V>>- Возможность строгой типизации. N>Ага-ага. "Возможность".
Ты не понял.
В сигнатурах методов прямо указываются типы, как аргументов, так и возвращаемого значения.
Не "аннотации", которе выглядят поздно-введёным в язык костылём, а прямо такой синтаксис языка изначально.
N>И как давно убрали автоконверсии между строками и числами?
Такой неявной конверсии в обе стороны нет. Есть только нявное приведение к string любого типа, когда такое приведение требуется согласно сигнатуре метода, типу переменнной или аргумента.
Это всё.
Конкретно числа тут не при чём, это общее правило для любых типов.
Точно так же как в дотнете WriteLine(object) вызывает у того метод ToString().
N>В Питоне этого дерьма не было изначально.
Да ладно?
А как же print работает? ))
V>>- Поддержка абстрактных классов и интерфейсов. Для абстрактного класса можно задать сигнатуру конструктора. N>Есть абстрактные классы.
Э, нет.
В Питоне абстрактных классов НЕТ.
Под тем же самым термином в Питоне понимается нечто другое, чем, скажем, в Java/Delphi/C#/C++/D/Go/Rust/Swift/Dart/ и т.д. до бесконечности.
V>>- Абстрактный итератор в языке, возможность описания собственных/произвольных итераторов (не путать с генераторами). N>Зачем нужен?
Затем же, зачем и в дотнете.
Просто еще одна удобная фишка в языке из многих десятков их.
Ведь не всегда удобно реализовать логику на yield, когда, скажем, необходимо передать экземпляр итератора "куда-то еще" для продолжения итерирования.
V>>- "чистая" реализация генераторов в виде корутин, что этот механизм применяется напрямую как для итерации, так и для задач, где в C# или Питоне 3.6 используют костыли async/await. N>Корутины есть отдельно. И чем именно async — костыли?
Потому что yiled не справился при абсолютно идентичной семантике stateless coroutines.
V>>- Абстрактный функциональный тип в языке, возможность описания произвольных своих функторов. N>Функторы есть.
Это ж не функторы и ты прекрасно об этом знаешь.
Это эмуляция функторов на методах, с потерей взаимозаменяемости в произвольном контексте со встроенным функциональным типом.
Т.е., функторы должны быть неотличимы от функционального типа, как функторы в C++ на основе типов с определённым operator()(), подаваемым в шаблоны, ожидающие ф-ии.
N>Абстрактный функциональный тип в языке — в стандартной библиотеке есть достаточно близкое.
В самом языке есть lambda и def, но получаемые с их помощью функциональные типы не абстрактные, а всегда конкретные типы конкретных созданных экземпляров.
Абстрактный же функциональный тип задан своей сигнатурой и позволяет производить автоматическую селекцию при выборе перегрузок в compile или run time.
Такой функциональности в Питоне нет.
V>>- Декомпозиция элементов языка (можно property описать как объект-шаблон). N>Зачем нужно?
Для дешевого порождения сложного property view.
Например, в дотнете есть TreeView, сам этот объект имеет коллекцию/св-во Nodes типа TreeNodeCollection и каждый Node имеет такое же точно св-во Nodes.
Но в реальности этой отдельной коллекции нет, бо ноды хранятся системным объектом, это лишь публичный View над внутренней коллекцией.
Так вот, засада дотнета в том, что пришлось описывать тип TreeNodeCollection и хранить переменную этого типа в TreeView и в TreeNode, чтобы синтаксически это выглядело как-то так:
nodeA.Nodes.Add(nodeB);
Т.е., на каждое такое св-во надо хранить лишнюю переменную.
И само такое св-во должно хранить переменную своего владельца.
Сие очевидная глупость, коль в момент обращения к св-ву на руках уже есть и тот и другой. ))
В общем, в PHP не надо хранить лишнюю переменную для такого view и в самом view не надо хранить ссылку на владельца.
V>>- Более последовательная и удобная работа с метаинформацией. N>Бездоказательно.
Если ты действительно готов в это погрузиться, то можно.
Но если ты достаточно знаешь Питон, то и сам в курсе.
V>>- Явное наличие неймспейсов, операторы области видимости '::'. N>Делается на импортах проще и удобнее.
А колокольчик насчёт константности и статических мемберов тут не прозвенел? ))
Оно не проще и не удобней. Оно делается через разыменование доп. переменной-словаря в текущем контексте и поиска нужной ф-ии или переменной внутри неё.
В то время как в PHP идёт непосредственное обращение к ф-ии или переменной, без лишнего уровня косвенности.
Ну и, перечислять все импортируемые ф-ии и переменные порой устанет рука.
Проще один раз импортировать неймспейс.
V>>- Строгие замыкания, возможность управления замыканием по имени или по-значению, а так же "уровнем" захвата переменной (вот эта вечная боль в JS — когда же надо создавать промежуточную переменную для вложенной иерархии анонимных ф-ий, а когда нет, вся эта боль решается, при надобности, явным use в PHP и указанием типа индирекции). N>Что такое "строгие" замыкания и чем они лучше обычных питоновых?
Строгие замыкания позволяют описывать — как именно замыкается контекст.
В Питоне, как и в JS, не зная тонкостей и не споткнувшись десяток раз, изначально не понятно, как именно захватывается переменная — по значению (например, по ссылочному значению захватываемой переменной, как захват this-функции в JS или enclosing context в Питоне) или по ссылке на неё (для ссылочной переменной будет ссылка на ссылку, как захват остальных переменных в JS). Этот момент — постоянный источник багов в JS и Питоне, которые (баги) регулярно допускают даже опытные программисты.
V>>- Анонимные классы. N>Зачем?
Примерно затем же, зачем и в джаве — по месту переопределить пару методов без полноценного объявления класса.
Особенно хорошо это смотрится прямо во время вызова new, как и в джаве, собсно.
V>>- Карринг и частичное применение в явном виде. N>functools.
Увы.
Ошибка карринга или частичного применения, совершённая в момент самого частичного применения, вылезет не в момент совершения ошибки, а где-то далеко после, в момент вызова порождённой ф-ии. Посему и считается не очень хорошим тоном злоупотребление partial.
V>>- Набор аргументов ф-ий можно рассматривать как один именованный тупл, т.е. оперировать им как единой сущностью (привет теориям типов). N>В Питоне из коробки, но зачем?
Нет там ничего из коробки.
Тупл — это рекорд, тип данных, состоящий из именованных типизированных полей.
А в Питоне аргументы — это просто нетипизированный безымянный список, плюс словарь для именованных аргументов.
Никакую полезную информацию из этого не извлечь, поэтому да, незачем.
V>>- Миксины, трейты, явное управление конфликтами: N>Всё есть.
Трейтов нет. Как всегда, под трейтами в Питоне понимается нечто, что трейтами не является, т.е. это название некоей прикладной библиотеки.
Миксинов нет. Есть множественное наследование и отсутствие ср-в разрешения конфликтов. Опять и снова, термин был взят неверно.
Это примерно того же уровня злоупотребления терминологией, как одно время было модно всё-что-угодно называть "монадами".
Типа, это придавало вес остальным рассуждениям автора. А на деле, в глазах грамотных коллег не придавало ни разу, бо ровно наоборот, сей незамысловат трюк бросается в глаза, т.е. опускает его автора до уровня клоуна, хотя бы автору и казалось обратное. ))
V>>- Туда же ключевое слово final; N>final делается при необходимости, но ни разу не потребовался.
А как он делается, если не секрет?
А главное, зачем, если любой объект можно легко поломать "на лету", записав что угодно в его системные или публичные кишки?
V>>- Управление уровнем ссылочности, разыменование ссылок. V>>- Т.е. фактически прямой выход скриптового исходника на возможность его "честной" компиляции в нейтив, в отличие от полукомпиляции в проекте CPython и других уже умерших проектах-экспериментах. N>CPython живее всех живых. О чём конкретно речь?
О принципиальной невозможности компиляции в нейтив.
Только интерпретация, только динамика.
Предварительная конверсия в "байт-код" ничего, по-сути, не меняет.
Это делал еще Лисп хрен знает когда. ))
Зато Схему уже компилировали в чистый нейтив.
А всего-то наложили несколько ограничений на Лисп.
V>>- Легкое расширение языка, см. модули паттерн-матчинга, модуля-аналога LINQ, модуль PHP-COM, модуль PHP-.Net, обертки над нейтивом и т.д. V>>- Наличие позднего статического связывания позволяет разрабатывать абсолютно-достоверную диагностику для кода, т.е. не нужны никакие среды-утилиты, это всё можно делать через встроенные ср-ва языка. N>Пример?
Например, у gdb есть модули для отладки Питона.
Потому что в Питоне не просто узнать, кто тебя вызвал.
В PHP — просто.
V>>Про синтаксису Питона не проходился только ленивый, это объект нескончаемого флейма. N>Сплошное хейтерство ((c) vdimas) от неосиляторов отступов.
В отличие от, я ни разу на эту тему не высказывался, по крайней мере на этом сайте.
Всё что я об этом думаю, я высказал еще в 96-м году, а последний раз достаточно резко в 2001-м.
С тех пор зарёкся, бо уже тогда началось вот это "ми-ми-ми" из разряда "мой любимый Питончик". Тьфу, гейство! ))
Там же дело не только в отступах.
Непоследовательность синтаксиса Питона резала глаза с самого начала.
Просто человек, он же такая свинья — ко всему привыкает.
Но уже тогда Питон привлёк к себе наших тестеров и они на ём сделали тестовый фреймворк.
Я был в ужасе, но ни на чём другом они бы сделать его не смогли бы.
А если бы могли — они работали бы не тестерами, а боевыми разработчиками за втрое большую ЗП.
Вот так я навсегда смирился с новым BASIC-ом в индустрии
V>>Напротив, синтаксис PHP никакого флейма не вызывает, там всё чисто изначально. N>Агащазз.
Тем не менее.
Споры вокруг PHP ведутся в основном в плане разнобоя name conventions, но это не синтаксис ни разу.
V>>Я не перечислял равные возможности, навроде генераторов yield и т.д., так шта, просьба не пытаться отвечать "а вот у Питона зато есть то-то и то-то" не проверив сначала, в каком виде "оно же" есть в PHP. N>Так ты объясни, что именно в конкретных реализациях тебе так больше нравится, потому что угадать твои предпочтения невозможно, а к практике они обычно ортогональны.
Я просто показывал, что PHP по своим св-вам более мощный и последовательный язык, чем Питон.
Питон — он ведь как JS по своему устройству, вид сбоку.
Каждый пользовательский объект в нём — просто объект-словарик.
Чем отличается конкретно Питон от вовсе незамысловатого JS? — что в его "словариках" потенциально содержится куча __специальных_значений__, которые простейший парсер/интерпретатор Питона пытается натягивать на исходник, что заметно замедляет даже сам парсинг, в сравнении с тем же JS.
И что "помойкой" язык делают не его св-ва, а его экосистема.
Так вот, происходящее с Питоном последние лет 10 лично мне видится как де жа вю.
Ну и, очевидно, что PHP и Питон — они из разных весовых категорий.
Питон из категории средневесов, типа JS.
PHP — это тяжеловес, типа Смолтолка или Перла.
А если объективно, по кач-вам дизайна языка и реализации внутренней механики PHP на пару весовых категорий повыше Смолтолка будет.
Просто под PHP никогда не было написано такой замечательной среды разработки, которая однажды была написана для Смолтолка.
И тот факт, что практически весь современный веб живёт на PHP — он ведь тоже говорит сам за себя, верно?
Не смотря на все "ми-ми-ми" в сторону Питона. ))
N>Задачи, где требуется суперскорость собственного кода, я на Питоне и не рассматриваю. Но таких 1-5%.
В точку. потому что разные подходы.
Если Питон ускоряют через обертки над нейтивными либами, то в PHP ускоряют именно евойный код.
Причём, для веба получается быстрее, чем даже в случае С/С++.
Там на обработку запроса выделяется grow-only аллокатор из пула, в конце запроса просто курсор аллокатора в начало сбрасывается и всех делов.
Т.е. затраты на выделение и освобождение памяти близки к абсолютному 0-лю.
И в случае полной типизации простые тулзы генерят честный С-код из PHP, получая затем нейтивный-оптимизированный.
Т.е. весь матан можно колбасить прямо в PHP — будет в наилучшем виде на выходе.
N>Что простой — согласен. Потому что в разы более логичный.
Я не вижу "логичности".
Я вижу простую модель отображения некоторых элементов синтаксиса/операторов на т.н. "специальные имена".
На этом логичность исчерпывается.
Простой язык ведь не обязан иметь простое внутреннее устройство, не?
А в случае с Питоном это именно так, отсюда все побочные эффекты и ограничения и, прямо скажем, видимый еще из 96-го года "потолок" развития.
V>>Сравнивать с ним убогие JS или Python можно лишь от упёртой агнажированности, т.е. поправ всякую объективность. N>Сказал самый упёртый в этом треде.
Я тут вообще над схваткой. ))
К Питону и PHP питаю одинаковые чувства, мне тут банально не понравились тонны неправды про Питон, поэтому встрял.
Слишком много успели вылить эмоционального и слишком много сугубо оценочных суждений.
Я лишь пытаюсь уравновесить всю эту необъективность техническими деталями.
Здравствуйте, 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>Спалился ты — на нечтении задачи. Опять невидимые собеседники чего-то намешали, видимо...
Здравствуйте, vdimas, Вы писали:
N>>Можешь реализовать парсер на split-ax, точная семантика кавычек не важна. Вот код "без библиотек":
V>Вот код без библиотек:
Хотя и не VBA, но зачтем. Разве не достаточно для доказательства неуклюжести VBA?
Здравствуйте, novitk, Вы писали:
V>>Вот код без библиотек: N>Хотя и не VBA, но зачтем.
Это VBS, т.е. чистый скрипт.
На VBA вместо CreateObject("Scripting.Dictionary") можно было просто написать new Dictionary().
Вот эти строки тоже были бы не нужны:
set stdin = WScript.stdin
set stdout = WScript.stdout
Считай их аналогом твоего import, чтобы не обращаться к "статическим" объектам через полное указание имени содержащего их модуля.
Остальное вполне чисто, хотя это гребанный Бэйсик.
=============
VBA — это встраиваемый полноценный VB, за исключением той тонкости, что вместо компиляции в нейтив работает виртуальная машинка над p-кодом.
Сам язык при этом уже обладает строгой типизацией, может импортировать в себя модули (импортировать их scope, поэтому достаточно простого new), но при этом всё еще ведёт себя как скриптовый — т.е. можно подменять на лету код, прямо даже в той строчке, на которой поставил breakpoint. Ну и весь REPL доступен в immediate-окошке.
Т.е. получается такой прикольный режим работы, что ты запустил прогу на отладку и продолжаешь прямо во время отладки писать код. Собсно, его обычно так и пишут на VB.
Но это же фишка скриптовых языков, верно? Но при этом доступна как строгая статическая типизация, так и динамика (если тип переменной просто Object).
Собсно, в самой среде VB в момент отладки внутри среды тоже работает виртуальная машинка над p-кодом, т.е. работает VBA, а нейтивный бинарник порождается лишь во время компиляции релиза. И что характерно, что с COM-объектами этот нейтивный бинарник работает даже эффективнее, чем когда с COM-объектами работаешь через С++, бо если пользовать смарт-поинтеры в С++, то часто получаются лишние парные AddRef/Release, а VB-компилятор все эти вещи чудесно оптимизирует. Оптимизация матана и просто циклов и условных ветвлений находится на уровне VC 6.0, т.е. на тот момент на грани прогресса. )) Но и по состоянию на сегодня генерируемый нейтивный код работает в разы быстрее, чем на Питоне.
Собсно, вот для чего я даю подробности устаревшего на ~20 лет VB/VBA/VBS — не для того, чтобы хвалить сам язык, а чтобы банально показать, что еще хрен знает когда уже была техническая возможность создавать высокоэффективные скриптовые языки (или даже их совместимое семейство), имеющие как строгую статическую типизацию, так и не строгую. Но, самое главное, имеющие практически неограниченные возможности по оптимизации релизного образа. Руководителем команды, разработавшей VBA, был один небезызвестный блоггер, который позже создал еще несколько проектов, один из которых тоже весьма известен.
Кароч, чего ходить вокруг да около — технологически интерпретатор Питона и сам дизайн языка представляет из себя нубство во плоти, в сравнении даже с гребанным VB. ))
Понятно, что усилиями десятков тысяч людей экосфера Питона обросла полезными либами, но в базе там сидит дремучее невежество.
И слишком многого ты из этой технологии не выжмешь, хоть укакайся.
Это того же уровня нубство, что и JS.
N>Разве не достаточно для доказательства неуклюжести VBA?
Да как-то недостаточно.
У меня не было цели доказать преимущество VBS, бо это технология 93-96-го года и с тех пор мало что поменялось.
Просто обсуждение рядом какого-то левого кода на VBS было совсем уже за рамками добра и зла. ))
Мало ли где, когда и кто написал на каком языке говнокод?
Такого на любом языке в Сети овердохрена.
Здравствуйте, vdimas, Вы писали:
_>>А оно умеет из коробки собрать C++ программу на любой платформе и с любым компилятором? ) V>А CMake умеет, пусть даже "не из каробки" собрать Go-программу на любой платформе и с любым компилятором? ))
Не из коробки с подобной задачей справится любая приличная система сборки)
V>Просто, модульное устройство Rake позволяет ему собирать что угодно. V>Под С/С++ конечно есть модули, что за вопрос?
Но в базовой поставке одного из важнейших языков программирования нет — это сразу говорит о направленности данной "системы сборки". )
_>>Мда? Простейший скрипт для SCons для сборки C++ приложения из одного исходного файла выглядит так: _>>
_>>Program('Source.cpp')
_>>
_>>И такой вот "сложнейший" файл проекта соберёт (а не сгенерирует нечто, что надо ещё запускать!) приложение на любой платформе, при этом само найдя на ней подходящий C++ компилятор.
V>Ну, попытай счастья: V>(Source.cpp) V>
V>#include <boost/intrusive_ptr.hpp>
V>
V>Бустов у меня несколько версий стоит. V>GLHF )) V>В общем, в реальной разработке нужно и компилятор конкретный указывать генератору и, самое главное, — дополнительные зависимости. V>Для CMake существует самая развитая на сегодня экосистема автоматического распространения зависимостей. V>Для SCons её не существует в природе от слова вообще.
Ну ты же понимаешь, что это всё элементарно пишется и единственное отличие CMake заключается в том, что у него подобный модуль уже входит в базовую поставку. Например у нас (хотя мы используем waf, а не scons, но это не суть) это выглядит так:
conf.load_libs('Qt Boost OpenSSL')
И кстати при простом внешнем виде это на самом деле внутри весьма не простая штука, т.к. она делает разные настройки в зависимости от целевой архитектуры.
V>Поэтому, для моего примера надо городить примерно такой огород на SCons: V>
V>Что тут не так? V>Если задать boost_prefix извне в кач-ве аргумента командной строки сборки, то скрипт надо переписывать. V>Если задать boost_prefix через переменную среды — скрипт надо переписывать. V>Если проводить поиск конкретной версии Boost, то скрипт займёт несколько экранов кода.
Ну и замечательно, напиши эти несколько экранов кода один раз, оформи в виде соответствующего модуля (для scons или waf Или GYP или другой системы (я кстати в последнее время стал слышать про некую Meson), не суть) и используй в дальнейшем везде и для всех библиотек.
_>>Можно увидеть как выглядит аналогичный файла на "правильной системе сборке", а не на "библиотеке для написания сценариев сборки"? )))
V>Можно. V>
V>Что тут так? V>По умолчанию будет просмотрена умолчательная nuget-директория. V>Можно подать как аргументы командной строки переменную BOOST_ROOT или Boost_DIR или BOOSTROOT или BOOST_INCLUDEDIR. V>Можно подать их в кач-ве переменной среды. V>Можно указать явно в скрипте, проверив предварительно, что переменная не установлена. V>Можно подать просто CMAKE_PREFIX_PATH для директории-"свалки" третьесторонних либ, где этих бустов много. V>Самих таких директорий-"свалок" у меня тоже может быть несколько — под разные принципиально проекты. V>CMAKE_PREFIX_PATH может быть списком, т.е. туда можно подать много "свалок" за раз и т.д. и т.п до бесконечности. V>Кароч, чувствуется глубокое "понимание" тысяч всевозможных ситуаций, возникающих во время сборки. V>Т.е. CMake прекрасно обучен выживать даже в условиях самого жуткого бардака, творящегося на машине разработчика. V>Он как раз весь этот бардак чудесно упорядочивает. ))
Да, неплохое решение, но всё равно оно уступает по удобству (естественно только для нас, а не вообще для всех) нашему кастомизированному решению. Хотя аналог нашего решения тоже можно без проблем (ну разве что будет подташнивать в процессе от синтаксиса языка) написать и на CMake. Тут всё дело именно в адаптированности под нас, в отличие от обобщённого решения из стандартной поставки.
_>>Сравнивать SCons/waf с CMake/GYP вообще говоря довольно сложно, т.к. у них разные базовые концепции. CMake/GYP — это просто генераторы нативных файлов проектов по некому DSL. Т.е. они создают нечто, зависящее от нативной системы сборки (типа файлов проектов VisualStudio), что надо потом ещё запускать отдельно. В то время как SCons/waf осуществляют всю сборку сами, используя от нативного тулчейна только компилятор, линкер и т.п. V>И это тоже минус, ИМХО. V>По этому поводу были жаркие споры где-то в первой половине 2000-х. V>Ср-ва конкретного тулчейна могут развиваться быстрее, чем некая система сборки. V>Потому что этих тулчейнов вагон и всё больше с каждым годом, а система сборки одна, за всеми не угонишься. V>Поэтому, CMake занимается лишь генерированием файлов сборки, а самой сборкой занимается уже сам тулчейн, бо они идут обязательно с некими никзоуровневыми ср-вами сборки, типа msbuild или make.
Как раз средства сборки у тулчейнов (все эти make/nmake/msbuild и т.п.) максимально убогие и не идут ни в какое сравнение с управлением процессом сборки в нормальных системах. Например как насчёт ручного управления синхронизацией параллельной сборки? Типа такого https://waf.io/book/#_task_processing.
V>В сухом остатке CMake сосредоточился на декларативном описании проектов и их зависимостей. V>Это всё, считай. Поэтому он выжил и пережил всех. V>Сейчас (грубо) 90% либ устанавливают себя вместе с артефактами, требуемыми CMake для вызова find_package. V>Для остальных популярных из оставшихся 10% есть это: V>https://github.com/Kitware/CMake/tree/master/Modules V>Всё вместе образует некую экосистему и тот самый "промышленный стандарт де-факто". V>Вот и сложилась такая ситуация, что если по ссылке нужного нет и некая либа не ставит с собой артефакты для CMake, то с вероятностью 99.99% ты найдешь готовый модуль конфига под CMake нужной тебе либы в сети.
Непонятно с чем ты споришь, если я тебе ясно написал в предыдущем сообщение, что считаю CMake оптимальным инструментом для распространения библиотек на гитхабе. ) Я его с удовольствием (т.к. тут не надо самому писать убогие CMakeLists файлы, а только запустить сборку готового) использую для сборки скаченных библиотек под нужные архитектуры. А вот потом уже настаёт пора других инструментов...
_>>В целом выбор подхода тут является делом вкуса. V>Дело не во вкусе, а в автоматизации. V>CMake даёт невиданную автоматизацию. V>Т.е. не "возможность автоматизации" (такую даёт любой тьюринг-полный ЯП), а именно изкаробки + возможности по наращиванию. V>На выходе под виндой nuget-пакет, под RHEL rpm и т.д. V>Везде с готовыми артефактами, зависимые от наших либ клиенты тоже пишут find_package и ву а ля. V>Всё "само" работает.
Если у вас конечным продуктом являются библиотеки, то выбор CMake является безусловно верным.
V>Э-э-э... это ж не стандартные либы, а третьесторонние. V>Таких можно нарыть подо что угодно.
Ну ставятся они из стандартного репозитория Питона одной командой (типа "pip install keyboard"). Если подскажешь на каком языке я смог бы добиться того же конечного результата быстрее, то с удовольствием гляну на него. Но что-то не припомню такого (даже с языком Autoit вроде придётся повозиться подольше, хотя эта задачка относится к его прямой специализации).
Здравствуйте, vdimas, Вы писали:
V>>>>>А так-то сам по себе PHP очень даже неплох, местами на голову выше Питона, разумеется. N>>Начни с обоснования этого тезиса, безаргументный ты наш... V>... V>- Возможность строгой типизации. V>...
Я правильно понимаю, что ты считаешь Питон языком со слабой типизацией? )
Здравствуйте, alex_public, Вы писали:
_>Но в базовой поставке одного из важнейших языков программирования нет — это сразу говорит о направленности данной "системы сборки". )
... _>Ну ты же понимаешь, что это всё элементарно пишется и единственное отличие CMake заключается в том, что у него подобный модуль уже входит в базовую поставку.
Если в Scons нет модуля под важнейшую либу С++ — это сразу говорит о направленности данной "системы сборки". ))
_>Например у нас (хотя мы используем waf, а не scons, но это не суть) это выглядит так: _>
_>conf.load_libs('Qt Boost OpenSSL')
_>
_>И кстати при простом внешнем виде это на самом деле внутри весьма не простая штука, т.к. она делает разные настройки в зависимости от целевой архитектуры.
А версии как указать?
А требуемые модули из библиотек для линковщика?
V>>Поэтому, для моего примера надо городить примерно такой огород на SCons: V>>
V>>Что тут не так? V>>Если задать boost_prefix извне в кач-ве аргумента командной строки сборки, то скрипт надо переписывать. V>>Если задать boost_prefix через переменную среды — скрипт надо переписывать. V>>Если проводить поиск конкретной версии Boost, то скрипт займёт несколько экранов кода.
_>Ну и замечательно, напиши эти несколько экранов кода один раз, оформи в виде соответствующего модуля (для scons или waf Или GYP или другой системы (я кстати в последнее время стал слышать про некую Meson), не суть) и используй в дальнейшем везде и для всех библиотек.
Это будет несколько экранов кода только чтобы обнаружить Буст нужной версии.
И еще несколько экранов кода, чтобы обыграть упомянутое до этого, плюс требования линковки с нужными либами из Буста.
Еще беда в том, что в Scons нет механизма, позволяющего задать значения переменных извне.
Можно подать аргументы извне, но в переменные ты будешь копировать внешние аргументы ручками.
Итого, самая нужная для целей сборки функциональность (задание внешних параметров для сборки) требует приседания вообще везде, не только для Буста.
_>Да, неплохое решение, но всё равно оно уступает по удобству (естественно только для нас, а не вообще для всех) нашему кастомизированному решению.
Я же не спорю.
У нас поверх CMake тоже сильно кастомизированное решение наверчено.
А так-то, если в конторе проекты типовые, т.е. количество типов проектов не много, то, ИМХО, можно даже без всяких внешних/готовых систем сборки запросто обойтись.
На коленке можно сбацать свою.
_>Например как насчёт ручного управления синхронизацией параллельной сборки?
Чем отличается от "не ручного"?
Я собираю так: make -j 12
Или так: msbuild blah-blah /m:12
Ввиду того, что проекты сгенерены со всеми зависимостями, "синхронизация" получается автоматической.
_>Ну ставятся они из стандартного репозитория Питона одной командой (типа "pip install keyboard").
Это сначала Питон надо установить.
Потом pip.
И только потом нужные библиотеки. ))
Можно было и нейтивную прогу ненамногим большего размера накатать.
SetWindowsHookEx прост в обращении, ему не требуется никакая логика/обвязка, т.е. такая обвязка ничего не экономит.
Здравствуйте, neFormal, Вы писали:
V>>- фиксили 4 года. F>а в луа, в луа-то пофиксили?
А есть такой реквест?
О чём тут вообще разговор, если на Питоне можно тупо "поломать" любой объект прямо в рантайме?
F>а, ну да. ты ж не видишь баги
Как ты думаешь, почему в С++ не фиксят UB?
Потому что не в состоянии исправить компилятор или потому что прямо в стандарте не в состоянии выработать однозначную спецификацию поведения для неоднозначных мест?
Здравствуйте, vdimas, Вы писали:
V>>>- фиксили 4 года. F>>а в луа, в луа-то пофиксили? V>А есть такой реквест? V>О чём тут вообще разговор, если на Питоне можно тупо "поломать" любой объект прямо в рантайме?
в плюсах тоже можно.
оправдания через 3, 2, 1...
F>>а, ну да. ты ж не видишь баги V>Как ты думаешь, почему в С++ не фиксят UB? V>Потому что не в состоянии исправить компилятор или потому что прямо в стандарте не в состоянии выработать однозначную спецификацию поведения для неоднозначных мест?
ты жопой-то не верти. думал, нашёл в гугле какие-то ссылки по запросу "python print nil", сразу сойдёшь за умного?
ты б хоть их почитал
Здравствуйте, vdimas, Вы писали:
_>>Но в базовой поставке одного из важнейших языков программирования нет — это сразу говорит о направленности данной "системы сборки". ) V>... _>>Ну ты же понимаешь, что это всё элементарно пишется и единственное отличие CMake заключается в том, что у него подобный модуль уже входит в базовую поставку. V>Если в Scons нет модуля под важнейшую либу С++ — это сразу говорит о направленности данной "системы сборки". ))
Например в waf из коробки идут модули поддержки для Boost и Qt, но мы их не используем, т.к. у нас используется своя система, универсальная на все библиотеки и с нужными нам особенностями.
_>>Например у нас (хотя мы используем waf, а не scons, но это не суть) это выглядит так: _>>
_>>conf.load_libs('Qt Boost OpenSSL')
_>>
_>>И кстати при простом внешнем виде это на самом деле внутри весьма не простая штука, т.к. она делает разные настройки в зависимости от целевой архитектуры. V>А версии как указать?
У нас всегда используется одна версия каждой библиотеки, собираемая под все нужные платформы и располагающаяся в нашей специальной области для библиотек.
V>А требуемые модули из библиотек для линковщика?
Это оно само делает, причём естественно разные для разных целевых архитектур.
_>>Ну и замечательно, напиши эти несколько экранов кода один раз, оформи в виде соответствующего модуля (для scons или waf Или GYP или другой системы (я кстати в последнее время стал слышать про некую Meson), не суть) и используй в дальнейшем везде и для всех библиотек. V>Это будет несколько экранов кода только чтобы обнаружить Буст нужной версии. V>И еще несколько экранов кода, чтобы обыграть упомянутое до этого, плюс требования линковки с нужными либами из Буста.
Ну так и в чём проблема то? Это же не требуется писать для каждого проекта, а делается один раз и навсегда.
V>Еще беда в том, что в Scons нет механизма, позволяющего задать значения переменных извне. V>Можно подать аргументы извне, но в переменные ты будешь копировать внешние аргументы ручками. V>Итого, самая нужная для целей сборки функциональность (задание внешних параметров для сборки) требует приседания вообще везде, не только для Буста.
Эээ что? Все переменные среды и все параметры командной строки доступны тебе в виде готового словаря.
_>>Например как насчёт ручного управления синхронизацией параллельной сборки? V>Чем отличается от "не ручного"? V>Я собираю так: make -j 12 V>Или так: msbuild blah-blah /m:12 V>Ввиду того, что проекты сгенерены со всеми зависимостями, "синхронизация" получается автоматической.
Да, если все зависимости легко устанавливаются, то граф параллельной сборки нормально строится в автоматическом режиме. Но это далеко не всегда так. Скажем если у тебя двухшаговое построение и при этом ты не знаешь точное имя создаваемого на промежуточном шаге файла, то корректно задать зависимость будет проблематично. Например у нас такое встречалось при построение документации, которая в начале создавалась как россыпь html и каких-то там сопутствующих файлов, а потом запаковывалась в архив. И тут проблему элементарно решают инструменты синхронизации (ты просто говоришь что одна задача должна исполняться строго после другой).
_>>Ну ставятся они из стандартного репозитория Питона одной командой (типа "pip install keyboard"). V>Это сначала Питон надо установить.
Был уже и у меня и у неё установлен.
V>Потом pip.
Входит в базовую поставку Питона.
V>И только потом нужные библиотеки. ))
Это да, так что можно добавить к тому моему исходнику ещё две строчки команды в консоли. ) Более того, эти две команды пришлось выполнить потом ещё и на компьютере подруги. )))
V>Можно было и нейтивную прогу ненамногим большего размера накатать. V>SetWindowsHookEx прост в обращении, ему не требуется никакая логика/обвязка, т.е. такая обвязка ничего не экономит.
Нуу в теории то конечно можно, только понадобилось бы на это не 1 минута, а несколько часов. И то если серьёзных подводных камней не встретилось бы. Если что, там самое сложное совсем не хоткей или работа с буфером обмена, а отправка текста. Потому как винда предоставляет нам только функцию эмуляции нажатия кнопки на клавиатуре, а нам требуется ввести в чужое приложение произвольный юникодный текст (как минимум с русским языком) — не знаю (не разбирался) насколько тривиальным будет подобное преобразование. А тут оно уже готовое, невидимо отрабатывает где-то в глубинах функции write.
Здравствуйте, vdimas, Вы писали:
_>>Я правильно понимаю, что ты считаешь Питон языком со слабой типизацией? ) V>С отсутствующей статической.
Это да, Питон полностью динамический. Но ты то писал про "Возможность строгой типизации" (кстати более корректно переводить strongly typed на русский как "сильная типизация"). Так вот в Питоне как раз от рождения сильная типизация, в отличие от того же PHP или JS. Для проверки этого очевидного факта предлагаю тебе просто вычислить выражение 2+"3" на Python, PHP, JS и сравнить результаты (самое забавное, что это будет 3 разных результата).
Здравствуйте, alex_public, Вы писали:
_>Это да, Питон полностью динамический. Но ты то писал про "Возможность строгой типизации" (кстати более корректно переводить strongly typed на русский как "сильная типизация"). Так вот в Питоне как раз от рождения сильная типизация, в отличие от того же PHP или JS. Для проверки этого очевидного факта предлагаю тебе просто вычислить выражение 2+"3" на Python
Это не строгость типизация, а явное приведение типов vs неявное.
Нестрогая типизация — это когда вместо bool ты можешь подать int.
Или когда в дотнете массив int[] можешь рассматривать как массив uint[].
Это будет нестрогая типизация.
Но не отсутствующая вовсе, бо ты не можешь рассматривать этот массив как double[] или string[].
В общем, твой пример показывает строгую динамическую типизацию для перечисленных языков, но показывает разную семантику конкретно оператора "+".
Смотри.
В Питоне оператор "+" можно перегружать, поэтому неявное преобразование типов невозможно из-за потенциальных возникающих конфликтов.
Сравни с тем, что неоднозначность ресолвинга оператора "+" в языке С++ возникает в момент всего-лишь компиляции.
А вот что делать в момент работы, когда уже поздно пить боржоми? ))
Далее.
В PHP оператор "+" складывает только числа.
Соответственно, пытается привести аргумент к числу.
Аналогично в Питоне при вызове print любое значение будет преобразовано в строку.
Это симметричные кейзы вокруг семантики, а не строгости типизации.
Ну и, складывать строки PHP не умеет. Он умеет делать их конкатенацию.
Собсно, во времена зарождения PHP использовать "+" для конкатенации строк считалось плохим тоном — это была сугубо паскалевская фишка.
Перл, PHP используют точку, VB использует амперсанд.
_>PHP, JS и сравнить результаты (самое забавное, что это будет 3 разных результата).
Забавное тут то, что в PHP вторая операция в разы быстрее первой:
$a = $a + "some text";
$a .= $"some text";
А вообще так никто не делает, там интерполяция строк отродясь жила, в отличие от Питона, где она появилась вовсе не сразу, т.е. еще на этапе синтаксического разбора d PHP собирается единый "пакет" для однократной конкатенации. Это самый быстрый вариант, поэтому используют именно его.
Сравнить с Питоном, в котором интерполяция строк выполняется каждый божий раз как с 0-ля, т.е. сама строка-шаблон каждый раз парсится. Думаю, в этом месте будет понятно, почему Питон как веб-язык так и не взлетел, хотя вебовские библиотеки были в нём почти сразу. Потому что это не живет от слова совсем. ))
Здравствуйте, neFormal, Вы писали:
_>>>Я правильно понимаю, что ты считаешь Питон языком со слабой типизацией? ) V>>С отсутствующей статической. F>даже строгую от статической не отличаешь. бхх
Учи матчасть.
Это перпендикулярные понятия, бхх.
=========
Ну и, так устоялось на практике (на правах просветительской лекции), что "строгая типизация" почти всегда применяется к статической.
А динамическая строгая типизация для большинства скриптовых языков умеет различать всего 4 базовых типа: строку, число, функцию и объект.
(в некоторых еще cons и array)
Но типы самих объектов такая типизация уже не различает, поэтому внутри семейства объектов работает утиная, а не строгая типизация.
Здравствуйте, alex_public, Вы писали:
V>>А версии как указать? _>У нас всегда используется одна версия каждой библиотеки, собираемая под все нужные платформы и располагающаяся в нашей специальной области для библиотек.
А собрать с какими-нить прошлами версиями, чтобы воспроизвести кейз клиента (коли возникнет)?
V>>А требуемые модули из библиотек для линковщика? _>Это оно само делает, причём естественно разные для разных целевых архитектур.
Т.е. однозначно определены не только версии библиотек и динамическая/статическая линковка? ))
V>>Это будет несколько экранов кода только чтобы обнаружить Буст нужной версии. V>>И еще несколько экранов кода, чтобы обыграть упомянутое до этого, плюс требования линковки с нужными либами из Буста. _>Ну так и в чём проблема то? Это же не требуется писать для каждого проекта, а делается один раз и навсегда.
Я же не против, я же говорю — можно даже самому систему сборки написать.
Обсуждаемые системы когда-то появились именно так.
V>>Еще беда в том, что в Scons нет механизма, позволяющего задать значения переменных извне. V>>Можно подать аргументы извне, но в переменные ты будешь копировать внешние аргументы ручками. V>>Итого, самая нужная для целей сборки функциональность (задание внешних параметров для сборки) требует приседания вообще везде, не только для Буста. _>Эээ что? Все переменные среды и все параметры командной строки доступны тебе в виде готового словаря.
О чём и речь. Из словаря эти параметры еще доставать нужно.
А так-то, считай, что "где-то сверху" уже были проинициализированы некоторые переменные.
_>>>Например как насчёт ручного управления синхронизацией параллельной сборки? V>>Чем отличается от "не ручного"? V>>Я собираю так: make -j 12 V>>Или так: msbuild blah-blah /m:12 V>>Ввиду того, что проекты сгенерены со всеми зависимостями, "синхронизация" получается автоматической. _>Да, если все зависимости легко устанавливаются
В CMake вообще нельзя успешно сгенерить проект, если требуемых зависимостей нет.
_>Например у нас такое встречалось при построение документации, которая в начале создавалась как россыпь html и каких-то там сопутствующих файлов, а потом запаковывалась в архив. И тут проблему элементарно решают инструменты синхронизации (ты просто говоришь что одна задача должна исполняться строго после другой).
Я понимаю о чём речь. ))
Это легко делается в том же make или Ant — вводятся искуственные цели и строится зависимость м/у ними.
Скажу только, что в CMake генерация и упаковка доки тоже автоматизирована точно так же, как генерация библиотек.
Например, у нас некая единая дока на несколько библиотек в пакете и просто указано, что дока строится из этих библиотек.
В итоге, нужные зависимости м/у целями сборки получаются автоматом — сборка доки произойдёт после сборки нужных библиотек, над которыми работает тул документации (у нас doxygen).
V>>Потом pip. _>Входит в базовую поставку Питона.
Есть сборки Linux, где Питон и pip ставятся отдельно (Ubuntu, например).
Т.е. Питон ставится со стандартной либой БЕЗ pip.
А потом уже сверху ставишь пакет python-pip, если нужен.
V>>Можно было и нейтивную прогу ненамногим большего размера накатать. V>>SetWindowsHookEx прост в обращении, ему не требуется никакая логика/обвязка, т.е. такая обвязка ничего не экономит. _>Нуу в теории то конечно можно, только понадобилось бы на это не 1 минута, а несколько часов.
Да не верю.
Просто у тебя на Питон рука набита, а на WinAPI — нет.
Было бы наоборот — и время было бы обратное там и там.
Собсно, засеки прикола ради, думаю, в 10 мин должен вложиться с 0-ля, т.е. начиная с гугла "SetWindowsHookEx", потом "keybd_event" или "SendInput".
_>И то если серьёзных подводных камней не встретилось бы. Если что, там самое сложное совсем не хоткей или работа с буфером обмена, а отправка текста. _>Потому как винда предоставляет нам только функцию эмуляции нажатия кнопки на клавиатуре, а нам требуется ввести в чужое приложение произвольный юникодный текст
Тогда однозначно SendInput вместо keybd_event.
См. флаг KEYEVENTF_UNICODE и это:
wVk
... If the dwFlags member specifies KEYEVENTF_UNICODE, then wVk must be 0.
wScan
... If dwFlags specifies KEYEVENTF_UNICODE, then wScan specifies a Unicode character that is to be sent to the foreground application.
Посылается нажатие, потом отпускание клавиши.
Можно прямо в одном пакете, бо SendInput позволяет пихать в систему несколько событий за раз.
Что характерно, сие удобно не только для юникода, а вообще для такой задачи — посылки текста в окошко.
Т.е. обычный 127-битный текст тоже удобно посылать таким макаром.
_>(как минимум с русским языком) — не знаю (не разбирался) насколько тривиальным будет подобное преобразование.
Единственно, обо что там можно споткнуться — это в UTF-16 big endian vs little endian.
Подобное "спотыкание" может отнять у тебя еще аж дополнительную минуту. ))
Остальное тривиально.
Я же говорю — в нейтиве эта функциональность делается проще всего.
Какая-нить дотнетная или скриптовая обертка вокруг этой функциональности будет страшной, потому что в одну и ту же ф-ию подаются разные типы структур и в обратном колбэке тоже подаются разные типы структур. На плюсах ты просто делаешь reinterpret_cast<> к нужному типу и ву а ля.
Ну и, все константы и ф-ии АПИ уже описаны, это тоже элемент удобства.
Здравствуйте, neFormal, Вы писали:
F>думал, нашёл в гугле какие-то ссылки по запросу "python print nil"
Я думаю, что мы общаемся на разных уровнях.
Я хорошо понимаю как работает Питон "унутре" и что с ним не так.
Ты же рассуждаешь сугубо как пользователь и всё врем пытаешься отослать собеседников к таким же ресурсам для домохозяек.
Парадокс бла-бла во всей красе.
Здравствуйте, vdimas, Вы писали:
V>Я думаю, что мы общаемся на разных уровнях. V>Я хорошо понимаю как работает Питон "унутре" и что с ним не так. V>Ты же рассуждаешь сугубо как пользователь и всё врем пытаешься отослать собеседников к таким же ресурсам для домохозяек. V>Парадокс бла-бла во всей красе.
стоило тебя поймать на вранье, как ты сразу же включил форсаж на сваливание из треда
