Python-сообщество

Domus
кхе кхе_)) \это понятно, что чем больще яп знаешь, тем выше шансы устроится получше, но я уже не такой молодой, и мозг не так хороши впитывает как в 20 лет, поэтому и интересовался, может зная  один питон, можно неплохо зарабатывать.

Я думаю тут все зависит от упорства. Привожу пример:

у меня отец с образованием геофизика после развала Супердержавы потерял работу, и ниче, в свои тридцать с гаком после года самостоятельной учебы уже ваял на C++/Turbovision програмулины для местного отделения банка, допиливал существующий софт на Паскале, и делал бухгалтерию на FoxPro, а потом на MS Access, для местного завода, и админил юникс-сервер в пенсионном фонде =) Так что сжать зубы и все получится =)

regall
Я думаю тут все зависит от упорства

Спасибо за поддержку ;)

Мну трицатнег - и ничё. Как говаривал дедушка Ленин - Учиться, Учиться и ещё раз Учиться!

helm2004
Мну трицатнег - и ничё.

т.е. вы только в 30 лет начали изучать программирование? похвально похвально..

helm2004
Kogrom а Вы слышали о утечке памяти?

А вы слышали об умных указателях? Эта альтернатива сборщику мусора в C++. Хотя мне сборщик мусора больше нравится.

Но речь то была о том, что C лучше, чем C++. А в си нет ни сборщика мусора, ни умных указателей. Так что C++ уж никак не хуже C.

helm2004
А о том как писать большой проэкт(который ко всему прочему ещё должен быть мультиплатформенный)?

Нет. В одиночку я не писал проектов на C++, превышающий 10000 строк. И приложения эти были только под Windows. Но это ничего не меняет.

Кстати, про кроссплатформенность. Взять хоть pyQt, хоть wxPython. Это же обёртки для библиотек, написанных на C++. Так что, хотя основа Питона и написана на C, дополнительные библиотеки часто пишутся на C++.

helm2004
Для микроконтроллера это одно, когда есть строгая спецификация, а для десктопа совсем другое.

У C++ есть стандарт. Я использую его, а не какие-то спецификации. И стандарт един хоть для микроконтроллера, хоть для десктопа. Хоть для Linux, хоть для Windows.

Если не уходить от темы, то у C++ есть такие преимущества перед Python: статическая типизация (дополнительная подпорка для ленивых программистов), скорость выполнения программ, свобода от интерпретатора.
У Python есть такие преимущества: лаконичность, динамическая типизация, которая даёт хорошую гибкость, модули, батарейки в комплекте. Хотя программисты их часто заменяют на более совершенные.

Kogrom
Так что C++ уж никак не хуже C.

Совсем некорректное сравнение. Это два разных языка для разных целей.

Kogrom
Кстати, про кроссплатформенность. Взять хоть pyQt, хоть wxPython. Это же обёртки для библиотек, написанных на C++. Так что, хотя основа Питона и написана на C, дополнительные библиотеки часто пишутся на C++.

А причём тут кроссплатформенность?

Kogrom
Кстати, про кроссплатформенность. Взять хоть pyQt, хоть wxPython. Это же обёртки для библиотек, написанных на C++. Так что, хотя основа Питона и написана на C, дополнительные библиотеки часто пишутся на C++.

Да, Qt на Си с плюшками рулит, потому, что для описания гуйни удобно использовать объектность (гвоздь в гроб gtk). И, в общем-то, это не зависит от языка. Однако, для большинства бинарных модулей для питона объектность не нужна, так как туда выносится только критичный к скорости код.

Kogrom
Кстати, про кроссплатформенность. Взять хоть pyQt, хоть wxPython. Это же обёртки для библиотек, написанных на C++. Так что, хотя основа Питона и написана на C, дополнительные библиотеки часто пишутся на C++.

Хм… Не знал, что Тролли писали Qt, как модули для питона…

Kogrom
батарейки в комплекте. Хотя программисты их часто заменяют на более совершенные.

Обычно не на более совершенные, а на свои велосипеды, так как не все знают, что в стандартных модулях есть много интересного.

Вот даже интересно стало, а чему бы вы отдали предпочтение python+c(cyton?) или python+c++. Ну и аргументы хотелось бы услышать.

ZZZ, gtk - объектно-ориентированный.
Сделан так, чтобы объектные библиотеки можно было легко и естественно создавать на любом языке программирования (при этом компиляторы и интерпретаторы требуют разного подхода).
Используйте Питон или С++ для конечного кода и оставьте Plain C разработчикам самого gtk.

По моему неплохо получилось.

ZZZ
Совсем некорректное сравнение. Это два разных языка для разных целей.

Не надо голословных утверждений. Можно писать на C++ полностью как на C. Можно только добавить шаблоны. Можно только классы. Можно только пространства имён. Можно использовать всю мощь STL.

В любом случае, C++ можно использовать как более удобный, безопасный, гибкий C. C++ может применяться везде, где уместно использование C, но не везде уместно использовать всю мощь C++.

ZZZ
А причём тут кроссплатформенность?

При том, что упомянутые библиотеки используют для создания кроссплатформенных приложений.

ZZZ
Да, Qt на Си с плюшками рулит, потому, что для описания гуйни удобно использовать объектность (гвоздь в гроб gtk). И, в общем-то, это не зависит от языка. Однако, для большинства бинарных модулей для питона объектность не нужна, так как туда выносится только критичный к скорости код.

Не распарсил.
gtk использует ООП. Да и не только gtk. Многие пытаются использовать ООП в C.
С другой стороны, на C++ совсем не обязательно писать, используя ООП. Некоторые люди используют C++, как C с шаблонами, например.

ZZZ
Хм… Не знал, что Тролли писали Qt, как модули для питона…

А кто это утверждает? Я говорю к тому, что программисты использующие Питон очень часто используют то, что написано на C++.

ZZZ

Kogrom
батарейки в комплекте. Хотя программисты их часто заменяют на более совершенные.

Обычно не на более совершенные, а на свои велосипеды, так как не все знают, что в стандартных модулях есть много интересного.

Я говорил о юнит-тестах, например. Когда я их тут упоминаю, то обычно мне советуют смотреть в сторону Nose. Или тот же Tk используют немногие.

PooH
Вот даже интересно стало, а чему бы вы отдали предпочтение python+c(cyton?) или python+c++. Ну и аргументы хотелось бы услышать.

Я писал C Extensions на Python C API, Cython и boost::python.

Однозначного решения нет.

Python C API знать нужно в любом случае. Разработка тяжела, требует очень много внимательности и тестирования (сегодня не заметил лишний Py_DECREF и все ломалось, причем не сразу). Но без этой основы - никуда.

Cython - очень здорово и быстро, хорош для отдельных не слишком больших модулей. Нужно знать Python C API чтобы понимать, что этот Cython нагенерит, где возможна оптимизация - и где нет. Генеренный код тяжело читать - а делать это приходится регулярно: шаг влево или вправо и можно получить все еще работающий модуль, который будет выполнятся медленней, чем просто написанный на Питоне. Плюс отсутствие сложных структур данных - Cpython это все же С, stl не хватает местами. На Python C API можно писать оптимальней - но делать это гораздо тяжелее.

boost::python. Для простых задач - из пушки по воробъям. К тому же сложнее в развертывании (setup.py можно настроить, но приходится делать больше телодвижений чем для C/Cpython). Если система сложная (или нужно завернуть С++ библиотеку, готовую или локальную, но имеющую ценность саму по себе) - лучший выбор.
Еще один ньюанс - приходится обращать внимание на время жизни объектов и конверторы Python <=> C++. Без ясного понимания легко напортачить. При использовании C/Cython такой проблемы как правило не возникает просто потому, что используются более примитивные конструкты. Т.е. если модуль на Cython дорастет до типовой сложности задач, под которые создавался boost::python - тоже прийдется обо всем заботиться. Но до такого чаще не доходит.
Очень красивая форма записи. Великолепный дизайн. Быстрый код. Отличная расширяемость - можно встроится в любом месте (часто нужно хорошо владеть метапрограммированием на С++, но это другая проблема)
В целом - мощнейший инструмент.

Как-то так. Эти инструменты не перекрывают друг друга - у каждого своя область применения.