Это везде так, и тем не менее, в C и потомках произошла эволюция от «переменных в начале» до «переменных где угодно». Я не готов сейчас обсуждать, почему так, но ещё одна важная причина, например, может состоять в том, что до некоторой строки кода у переменной может не быть разумного значения, поэтому автор вынужден объявлять переменную и присваивать ей бессмысленное «пустое» значение (или неявное значение) что плохо, а иногда и просто невозможно. Это может быть даже ударом по системе типов и по безопасности кода.
Соглашусь, но тогда давайте и обучать именно ему, с объектами и современным стилем. Тут в основном пишут, что это всё «излишества», вредные школьникам, а нужен язык, в котором нет ничего лишнего.
Речь про локальные переменные функций. На мой взгляд это очень полезное правило и не только для школьников. Оно дисциплинирует, предохраняет от ряда глупых ошибок, улучшает стиль и читаемость кода.
Вот видите, у всех свой взгляд. С моей колокольни оно портит дисциплину, ухудшает стиль у читаемость кода. Почему? Ну да потому, что мы разносим инициализацию переменной и контекст её использования. Собственно, в большинстве современных языков это правило убрано именно из стилистических (но и не только) соображений.
ИМХО школьникам это не обязательно
…
классические алгоритмы. Их удобно изучать на Паскале.
Я не знаю, что такое «классические алгоритмы». На Паскале удобно изучать алгоритмы, предназначенные для изучения Паскаля. Есть миллион задач, в которых требуется сопоставить произвольному ключу произвольное значение, например, слову — количество вхождений данного слова в документ. Не понимаю, почему школьнику это знать менее полезно, чем частный случай, где ключ представляет собой целочисленный индекс. В Паскале такой структуры данных нет… ну вот просто потому что нет, потому что автор её не любит.
Я понимаю вашу точку зрения, но не вижу ни одной причины, по которой любой современный язык хуже Паскаля именно для стандартных учебниковских алгоритмов. Если заглянуть на Rosetta code, то все они выглядят примерно одинаково и на Паскале, и на Питоне, и на современном Бейсике.
Проблема в том, что любой язык страдает какой-нибудь аналогичной идиосинкразией. В Паскале почему-то есть массивы, но нет ассоциативных массивов. Длина строк ограничена 255 символами. Переменные можно описывать только в начале функций. Аналогично могу вспомнить про Бейсик, да и не только. Так что идеала не найти.
Сегодня есть, завтра нет. Эту фирму бросало за последние десять лет во все стороны, и я бы не стал глубоко внедрять в систему образования технологию, которая завтра по щелчку пальцев меняет статус.
Ну если мы ссылаемся на рейтинг TIOBE, то его там нет :)
Там всё-таки «Delphi/Object Pascal», поэтому я и говорил, что Pascal язык мёртвый. Жива только конкретная и довольно специфическая его разновидность.
Вот специально не стал об этом говорить :) Закидон, но его проблемность слишком преувеличена. В том же Бейсике ведь тоже нет {} или begin/end, есть только «конец блока», а начало блока определяется по умолчанию. Т.е. если в Бейсике мы пишем For… Next, то в Питоне то же самое, но просто без Next. И ничего, с Бейсика переходили.
Интересно почему? Можно подробнее?
Проблема Питона и других динамических языков в том, что очень много ошибок отлавливается только на этапе выполнения. Можно очень легко словить в рантайме банальную синтаксическую ошибку вида «несбалансированные скобки», не говоря уже о более серьёзных вещах.
Таким образом, использование Питона в больших объёмах требует достаточно высокой дисциплины регулярного тестирования и покрытия тестами кода.
Я сам пишу довольно много на Питоне, но в целом это именно что скрипты склейки, скрипты тестирования и другие не очень объёмные вещи.
Есть масса одноразового кода, для которого нет смысла тратить время на обдумывание архитектуры. Питон даёт большую свободу и разгружает голову. Один только duck typing чего стоит — когда я могу написать функцию, которая принимает на вход некий объект, и при этом можно ей по факту передать любые объекты, классы которых не связаны в общую иерархию. В Java/C++ и т.п. такие штуки приходится продумывать тщательнее и заранее.
В рейтинге сказано именно «Delphi» (а не Lazarus и не Pascal), а Delphi это проприетарная и очень дорогая среда программирования. Мне кажется неплохим языком и C#, но всё же для школы я бы выбрал что-то более нейтральное и уж точно не платное.
Применительно к школе — Python самый обычный современный мейнстримный язык без каких-либо закидонов, архаизмов и художеств автора («я так вижу»). В некотором смысле эта серость и делает его пригодным для школы: другие языки не должны будут вызвать какого-то огромного культурного шока.
Я сам учился на Бейсике ZX Spectrum, потом на QuickBasic. Так вот по ощущениям от программирования Python это шаг в ту же самую сторону. Достаточно ненапряжно с ним работать (хотя проблемы растут с общим размером кодовой базы, вот масштабные проекты я бы на нём делать как раз поостерёгся, если речь не о «склеивании», а именно о написании большого количества кода).
А я говорил иное: 1) в школе Питон не нужен; 2) важен не язык, а алгоритмы.
Вообще мы тут свободно общаемся, а если бы существовала реальная дискуссия о языке в школе, то там бы аргументы были бы совсем другими. Все бы согласились, что важны алгоритмы, но тут же неизбежно бы возник вопрос о языке. И здесь бы любой живой (поддерживаемый, развивающийся) язык с пологой кривой обучения заранее был бы обречён на победу, так же как английский выигрывает у древнегреческого, пусть даже на последнем писали Гомер и Аристофан.
Я потерял нить разговора. Разве кто-то спорил с тем, что можно обойтись без Питона? Конечно, можно. Вопрос исключительно в кривой обучения.
Мы сейчас используем Питон именно в качестве скриптового языка для проекта, в котором участвует около 10 разработчиков, но главное — это не количество разработчиков, а количество библиотек, их очень много, так что объёмы кода не подсчитывал.
По факту доля всех создаваемых в мире ОС (вроде Amoeba project) очень небольшая от объема всего создаваемого в мире софта. Поэтому думаю, что причина популярности другая.
Причём тут ОС? Я же вам приводил примеры: абсолютно что угодно, связанное с Qt, CORBA, MPI. Любая ситуация, при которой требуется «подружить» друг с другом NLP (языковые) модули, визуализацию/графики, математику, классификаторы/machine learning и т.п.
Т.е. если объем моего проекта меньше 10М SLOC, и команда меньше 1000 человек, то мне ОО клей не нужен. Это самое я и говорил выше.
Я не знаю, откуда вы берёте эти цифры. Если в эти люди записывать всех авторов описанных библиотек, то да, примерно так и получается. У меня все проекты попадают в разряд, где нужно.
Это означает, что ваши проекты пишутся очень небольшой командой и состоят из достаточно однородных (по языку и идеологии) проектов. В больших системах это попросту невозможно.
Возьмите любой из них и укажите, где конкретно я бы мог воспользоваться ОО «клеем» и что это даст?
Смотрите, я не говорю, что это нужно в любом конкретном проекте. Вполне вероятно, что вам это не нужно по причине их хорошей внутренней связности (т.к. пишутся одной небольшой командой или одним человеком на одном языке).
Собственно, Россум прямо пишет вот что: «My original motivation for creating Python was the perceived need for a higher level language in the Amoeba project. I realized that the development of system administration utilities in C was taking too long. Moreover, doing these in the Bourne shell wouldn’t work for a variety of reasons. The most important one was that as a distributed micro-kernel system with a radically new design, Amoeba’s primitive operations were very different (and finer-grain) than the traditional primitive operations available in the Bourne shell. So there was a need for a language that would “bridge the gap between C and the shell.” For a long time, this was Python’s main catchphrase.»
То есть видите, речь идёт именно о создании более высокоуровневого «клея», занимающего промежуточное положение между C и сценариями оболочки. Текущая популярность языка объясняется тем, что по факту огромное количество задач нуждается именно в таком подходе. Все ли 100% нуждаются? Конечно, нет. Но нельзя распространять частный опыт на весь мир. Вы можете использовать Python просто как высокоуровневый язык с развитыми средствами… да чего бы то ни было. Но можете и не использовать, конечно, это уже вопрос вкуса.
Т.е. во многих сложных задачах (имею в виду теор. оценку для наихудшего случая) 99.9% кода я пишу и отлаживаю на другом языке,
Практически в любой сложной задаче 99.9% кода вы НЕ пишете, за вас его уже написали (если вы в одиночку пишете систему целиком, «сложной» назвать её язык не поворачивается), соответственно
Зачем мне привлекать другой язык только для этого 0.1% примитивного кода?
оставшиеся 0.1% кода нельзя назвать примитивными, иначе бы смысла в создаваемой системе не было бы.
Штука в том, что как раз задача получения данных из одного места, преобразования в другой вид данных и передачи на вход следующему алгоритму на практике оказывается достаточно муторной. Собственно, можно посмотреть любую кроссплатформенную/кроссязыковую библиотеку (Qt, MPI или любой вид CORBA), чтобы увидеть, что языки вроде C++ требуют написания большого количества boilerplate кода в качестве клея между модулями. Это реальная проблема.
но скрипт, который запускает сначала одну программу, потом другую, представляется мне наименее важным во всем проекте
Смотрите на проблему шире. Не скрипт, который оперирует текстовым вводом-выводом, а именно объектно-ориентированный «клей», который может вытащить результат работы одной библиотеки в виде коллекции векторов и тут же передать другой для построения в виде графиков.
Я сам пишу почти всё на C++ (так жизнь сложилась), но не могу отрицать очевидное: эквивалентные GUI-программы C++ и Python на Qt по объёму отличаются раза в два, концептуально C++ код тоже гораздо сложнее, а по факту это тот самый «клей», который требуется для замазывания щелей между идеологиями C++ и Qt. Меня самого это не очень напрягает, но объективно кривая обучения получается куда круче, а выучиваются не полезные вещи, а та самая малополезная «замазка».
В целом согласен, но в данном конкретном случае думаю, что Python задержится. Вон посмотрите на нишу C++: уже года с 1990го примерно сидит крепко, и никто не выбивает.
Prolog и иже с ним — это мертворожденная концепция, которая казалась интересной исключительно в соответствующий исторический период. Можно порассуждать, почему было так, и почему сейчас это не так.
Python же (я не фанат Питона, но надо признавать очевидное) решает гораздо более приземлённую задачу: обеспечить лёгким инструментарием тех, кому не интересно становиться системными программистами. Да, формально OpenCV вообще сделана для C++, но вы на практике попробуйте сравнить объём знаний и труда, потребные для реального соединения этих технологий. В этом смысле ниша Python может заполниться другим языком, более современным, но сама по себе она никуда не денется.
ОК, тогда выражусь проще: да, с помощью макро вам НЕ удастся убыстрить код. Конечно, вы можете использовать специнструкции где угодно, но это не про макросы, а про специнструкции.
Безусловно. Вы о теме или о конкретной книге? Если о книге, то да, книга плохая, согласен. По теме же можно написать и интереснее. Без объёмного рутинного кода. В каком-нибудь Седжвике, «Алгоритмы на С++» тоже кода хватает. Ну подход у автора такой, что ж сделаешь.
Вот видите, у всех свой взгляд. С моей колокольни оно портит дисциплину, ухудшает стиль у читаемость кода. Почему? Ну да потому, что мы разносим инициализацию переменной и контекст её использования. Собственно, в большинстве современных языков это правило убрано именно из стилистических (но и не только) соображений.
…
Я не знаю, что такое «классические алгоритмы». На Паскале удобно изучать алгоритмы, предназначенные для изучения Паскаля. Есть миллион задач, в которых требуется сопоставить произвольному ключу произвольное значение, например, слову — количество вхождений данного слова в документ. Не понимаю, почему школьнику это знать менее полезно, чем частный случай, где ключ представляет собой целочисленный индекс. В Паскале такой структуры данных нет… ну вот просто потому что нет, потому что автор её не любит.
Я понимаю вашу точку зрения, но не вижу ни одной причины, по которой любой современный язык хуже Паскаля именно для стандартных учебниковских алгоритмов. Если заглянуть на Rosetta code, то все они выглядят примерно одинаково и на Паскале, и на Питоне, и на современном Бейсике.
Там всё-таки «Delphi/Object Pascal», поэтому я и говорил, что Pascal язык мёртвый. Жива только конкретная и довольно специфическая его разновидность.
Вот специально не стал об этом говорить :) Закидон, но его проблемность слишком преувеличена. В том же Бейсике ведь тоже нет {} или begin/end, есть только «конец блока», а начало блока определяется по умолчанию. Т.е. если в Бейсике мы пишем For… Next, то в Питоне то же самое, но просто без Next. И ничего, с Бейсика переходили.
Проблема Питона и других динамических языков в том, что очень много ошибок отлавливается только на этапе выполнения. Можно очень легко словить в рантайме банальную синтаксическую ошибку вида «несбалансированные скобки», не говоря уже о более серьёзных вещах.
Таким образом, использование Питона в больших объёмах требует достаточно высокой дисциплины регулярного тестирования и покрытия тестами кода.
Я сам пишу довольно много на Питоне, но в целом это именно что скрипты склейки, скрипты тестирования и другие не очень объёмные вещи.
Есть масса одноразового кода, для которого нет смысла тратить время на обдумывание архитектуры. Питон даёт большую свободу и разгружает голову. Один только duck typing чего стоит — когда я могу написать функцию, которая принимает на вход некий объект, и при этом можно ей по факту передать любые объекты, классы которых не связаны в общую иерархию. В Java/C++ и т.п. такие штуки приходится продумывать тщательнее и заранее.
Я сам учился на Бейсике ZX Spectrum, потом на QuickBasic. Так вот по ощущениям от программирования Python это шаг в ту же самую сторону. Достаточно ненапряжно с ним работать (хотя проблемы растут с общим размером кодовой базы, вот масштабные проекты я бы на нём делать как раз поостерёгся, если речь не о «склеивании», а именно о написании большого количества кода).
Вообще мы тут свободно общаемся, а если бы существовала реальная дискуссия о языке в школе, то там бы аргументы были бы совсем другими. Все бы согласились, что важны алгоритмы, но тут же неизбежно бы возник вопрос о языке. И здесь бы любой живой (поддерживаемый, развивающийся) язык с пологой кривой обучения заранее был бы обречён на победу, так же как английский выигрывает у древнегреческого, пусть даже на последнем писали Гомер и Аристофан.
Мы сейчас используем Питон именно в качестве скриптового языка для проекта, в котором участвует около 10 разработчиков, но главное — это не количество разработчиков, а количество библиотек, их очень много, так что объёмы кода не подсчитывал.
Причём тут ОС? Я же вам приводил примеры: абсолютно что угодно, связанное с Qt, CORBA, MPI. Любая ситуация, при которой требуется «подружить» друг с другом NLP (языковые) модули, визуализацию/графики, математику, классификаторы/machine learning и т.п.
Я не знаю, откуда вы берёте эти цифры. Если в эти люди записывать всех авторов описанных библиотек, то да, примерно так и получается. У меня все проекты попадают в разряд, где нужно.
Смотрите, я не говорю, что это нужно в любом конкретном проекте. Вполне вероятно, что вам это не нужно по причине их хорошей внутренней связности (т.к. пишутся одной небольшой командой или одним человеком на одном языке).
Собственно, Россум прямо пишет вот что: «My original motivation for creating Python was the perceived need for a higher level language in the Amoeba project. I realized that the development of system administration utilities in C was taking too long. Moreover, doing these in the Bourne shell wouldn’t work for a variety of reasons. The most important one was that as a distributed micro-kernel system with a radically new design, Amoeba’s primitive operations were very different (and finer-grain) than the traditional primitive operations available in the Bourne shell. So there was a need for a language that would “bridge the gap between C and the shell.” For a long time, this was Python’s main catchphrase.»
То есть видите, речь идёт именно о создании более высокоуровневого «клея», занимающего промежуточное положение между C и сценариями оболочки. Текущая популярность языка объясняется тем, что по факту огромное количество задач нуждается именно в таком подходе. Все ли 100% нуждаются? Конечно, нет. Но нельзя распространять частный опыт на весь мир. Вы можете использовать Python просто как высокоуровневый язык с развитыми средствами… да чего бы то ни было. Но можете и не использовать, конечно, это уже вопрос вкуса.
оставшиеся 0.1% кода нельзя назвать примитивными, иначе бы смысла в создаваемой системе не было бы.
Штука в том, что как раз задача получения данных из одного места, преобразования в другой вид данных и передачи на вход следующему алгоритму на практике оказывается достаточно муторной. Собственно, можно посмотреть любую кроссплатформенную/кроссязыковую библиотеку (Qt, MPI или любой вид CORBA), чтобы увидеть, что языки вроде C++ требуют написания большого количества boilerplate кода в качестве клея между модулями. Это реальная проблема.
Смотрите на проблему шире. Не скрипт, который оперирует текстовым вводом-выводом, а именно объектно-ориентированный «клей», который может вытащить результат работы одной библиотеки в виде коллекции векторов и тут же передать другой для построения в виде графиков.
Я сам пишу почти всё на C++ (так жизнь сложилась), но не могу отрицать очевидное: эквивалентные GUI-программы C++ и Python на Qt по объёму отличаются раза в два, концептуально C++ код тоже гораздо сложнее, а по факту это тот самый «клей», который требуется для замазывания щелей между идеологиями C++ и Qt. Меня самого это не очень напрягает, но объективно кривая обучения получается куда круче, а выучиваются не полезные вещи, а та самая малополезная «замазка».
Python же (я не фанат Питона, но надо признавать очевидное) решает гораздо более приземлённую задачу: обеспечить лёгким инструментарием тех, кому не интересно становиться системными программистами. Да, формально OpenCV вообще сделана для C++, но вы на практике попробуйте сравнить объём знаний и труда, потребные для реального соединения этих технологий. В этом смысле ниша Python может заполниться другим языком, более современным, но сама по себе она никуда не денется.