> Это у Вас, батенька, глюки )))Дитятко, если бы ты чётко и ясно изложил свою агенду, мне бы не пришлось фантазировать. Но ты, заметь, так и не сказал чего ты хочешь доказать. Ты в курсе что доказательства не существуют в вакууме, и их нельзя отрывать от доказываемого утверждения. Что ты доказываешь?
> 1. Python не функционален […] я подразумеваю не отсутствие тьюринг-полноты, а в разы более низкое быстродействие даже по сравнению с другими интерпретаторами, не говоря уже о компилируемых языках программирования.
Ты не пугай так меня больше: "не функционален" при каком то кастомном определении функциональности языка. Будет лучше, если в следующий раз ты _сначала_ кастомное определение дашь, а потом будешь его использовать.
По теме ж, скорость работы пайтона ограничивает сферу его применимости, не более того. Пускай первым кинет камень тот, у кого нет ограничений на сферу применимости, вытекающих из фич языка.
> 2. Если "программист" знает только Python, то он не в состоянии изучить исходный код библиотек на C/C++ […]
А если он знает не только пайтон, то пайтон прекращает быть калькулятором и становится языком программирования, так чтоль? Или что ты там доказываешь? Ты глупости то не неси, а то люди могут подумать, что глупость не свойство твоих высказываний, а свойство тебя.
Или может я не понял к чему ты это сказал? Может быть, даже скорее всего: слишком уж глупость выходит, ты выглядишь умнее. Ну поясни тогда, что ты хотел этим сказать.
> 3. Профессиональный программист, свободно пишуший на двух десятках языках программирования, […], ему удобней будет использовать эту библиотеку из того же C. Исключительно ради возможности бесшовной отладки и упрощения дальнейшей поддержки.
Совершенно неочевидное высказывание? Почему ему будет удобнее? Я последнее время использую раст там, где раньше я использовал lisp (я в целом лисп предпочитаю пайтону, в силу ностальгических причин), но я не буду заменять lisp на C. Блин, там где можно за полчаса накидать готовую программу, на C придётся два дня писать. Уже только поэтому я не буду менять lisp на C, хотя на пайтон мог бы, если бы лиспа под рукой не оказалось бы. Мне приходилось пару раз на пайтоне писать вещи 1к+ строк, и он оставил весьма приятное впечатление.
В пайтоне довольно удобный ffi насколько я слышал, использовать C'шный код не сложнее чем из C. Но при этом тебе доступны фишки пайтона, и слелать матч регекспом, или итератор по файлам в директории, фильтрующий их по маске, или собрать имена файлов в динамический массив, или сделать из файла с изображением массив пикселей и наложить пару фильтров, или залить этот файлик на сервер посредством https, всё это делается на пайтоне вполпинка. То есть "вполпинка", ссылаясь на половину, не передаёт того насколько это проще в пайтоне, чем на C. И я не знаю каким местом надо думать, чтобы при наличии выбора, выбирать длинный и тернистый путь.
На C++ разрыв в сложности будет меньше чем с C, но я вот постоянно экспериментирую со "скриптами" на расте (который ещё проще в использовании чем C++), и как бы мне не хотелось доказать, что растом можно заменить пайтон и lisp, я не скажу этого, ибо это неправда. Можно, но придётся раза в два-три больше времени тратить на то же самое.
> 4. […]
Я не совсем понял в чём поинт. Это выглядит как старческое брюзжание о том, что кто-то что-то не то советует с пайтоном делать, и что пайтон не язык программирования. Но, по первой части я отказываюсь общаться без а) конкретных примеров тому, и б) обоснования того, почему нам не начхать на то, что кто-то там думает о пайтоне. Я не собираюсь тут выступать защитником соломенного чучела, которое ты искусно создал так, чтобы потом блестяще его победить. По второй части, я б рекомендовал тебе обосновать его с отсылками к какому-нибудь общепринятому определению языка программирования.
Ты хочешь технарскую дискуссию? Ну так соответствуй. Не надо придумывать новых определений для "функционального языка" и для "языка программирования". Придумывать такие определения понятиям, которые делают доказываемое утаерждение верным -- это явный признак политической демагогии, а не технической дискуссии.
