Программирование детям?

[Обедающий философ]

Если это, то знаю. И не понимаю, чем это лучше хорошего интерактивного отладчика в любой вменяемой IDE.

Да, это оно! А лучше тем, что каждую функцию можно проверить за секунду с любыми пришедшими в эту же секунду в голову параметрами.

Что до синтаксиса, то не припомню сейчас всего.

Ну хотя бы что-то?

[Lifewalker]

А лучше тем, что каждую функцию можно проверить за секунду с любыми пришедшими в эту же секунду в голову параметрами

Разве во вменяемых IDE так делать нельзя? А если и нельзя, то я как поклонник жёсткого стиля программирования не понимаю, зачем это надо? Параметры могут принимать строго определённый диапазон значений. Все прочие - в исключения. Проверяется тестами.

Что до синтаксиса, ну честно не помню Помню только что вольное объявление через определение вернуло меня на 25 лет назад во времена GW-BASICa. Убегали от интерпретаторного бреда и к нему же вернулись.

Приведите пример, где бы вам помешал такой способ выделения блоков.

Писал какую-то мелкую фигулинку пробы ради и очень подивился. Убираю табуляцию, строка с присваиванием (кажется) вылетает из области видимости и рвёт в клочья нижележащий код. В результате программа валится на бок. Возвращаю табуляцию на место - всё пашет как задумано. Не бред ли?

[Обедающий философ]

жёсткого стиля программирования

Это что?

Проверяется тестами.

Ну, а тесты в вашем случае в чём заключаются?

Помню только что вольное объявление через определение вернуло меня на 25 лет назад во времена GW-BASICa. Убегали от интерпретаторного бреда и к нему же вернулись.

Ну вот, вполне конкретная претензия. Я так понимаю, вам не нравится динамическая типизация и сборка мусора (без которой первое невозможно). Но я не понимаю, что вы увидели в этом плохого, помимо того, что скорость выполнения будет чуть меньше. И помимо того, что это ассоциируется у вас с бейсиком 25-летней давности. Я не особо вникал в причины, по которым люди не любят бейсик, но я готов поспорить, что это не то, что вы назвали.

Убираю табуляцию, строка с присваиванием (кажется) вылетает из области видимости и рвёт в клочья нижележащий код. В результате программа валится на бок. Возвращаю табуляцию на место - всё пашет как задумано. Не бред ли?

Ну не знаю. Я когда с ним игрался, писал в интерактивном режиме, а потом, ежели надо, переносил в текстовый редактор. Кроме того, хороший стиль программирования предполагает, что любая функция занимает не более одного экрана (25 строк).

[Lifewalker]

Жёсткий стиль программирования — это когда как в Эйфеле: проверяем всё до точки входа в процедуру, в процессе выполнения и после выхода из неё. Никакой враг не пролезет. Шаг влево, шаг вправо — расс исключение.

Проверяется типовыми юнит-тестами. Любая вменяемая IDE их сейчас может нагенерить по желанию для класса или модуля по вкусу.

Я не совсем понял где связь между динамической типизаций, сборкой мусора и возможностью вылета программы по обращению по не объявленной и неопределённой переменной. То есть где связь с грехом, которым страдают интерпретаторы а-ля Бейсик уж лет 30 как?

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

Код: [Выделить]

...
если а=1 то
   оператор01
  оператор02
 оператор03
оператор04
...
Вопрос. С точки зрения Питонового программиста, на каком операторе заканчивается условие? Поясните свою точку зрения.

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

[Обедающий философ]

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

Код: [Выделить]

...
если а=1 то
   оператор01
  оператор02
 оператор03
оператор04
...
Вопрос. С точки зрения Питонового программиста, на каком операторе заканчивается условие? Поясните свою точку зрения.

Я не стал гадать и спросил у ясеня питона, и вот что он мне ответил:

Код: [Выделить]

In [5]: if a==0:
   ...:     print "a"
   ...:    print "b"
------------------------------------------------------------
IndentationError: unindent does not match any outer indentation level (<ipython console>, line 3)
По-моему, вполне исчерпывающий ответ, не так ли?

Я не совсем понял где связь между динамической типизаций, сборкой мусора и возможностью вылета программы по обращению по не объявленной и неопределённой переменной. То есть где связь с грехом, которым страдают интерпретаторы а-ля Бейсик уж лет 30 как?

Вот я тоже не совсем понял. Какая связь между грехом, которым страдают отдельные 30-летние бейсики, и самими фактами интерпретации, сборки мусора и динамический типизации? Вы же против них выступаете, насколько я понял. Питон, скажем, не вылетает в указанном случае.

Жёсткий стиль программирования — это когда как в Эйфеле: проверяем всё до точки входа в процедуру, в процессе выполнения и после выхода из неё. Никакой враг не пролезет. Шаг влево, шаг вправо — расс исключение.

А что вам мешает на питоне так же поступать? Правда, я не вижу преимуществ подобного подхода. Тратится время, резко падает читаемость, а всего предусмотреть всё равно нельзя. Проверки, на мой взгляд, имеют смысл разве что в отношении входных данных. А ежели где-то ещё вылезет ошибка - то можно завсегда добавить проверку постфактум.

Проверяется типовыми юнит-тестами. Любая вменяемая IDE их сейчас может нагенерить по желанию для класса или модуля по вкусу.

Откровенно говоря, не сталкивался с подобным понятием. Можно пример? И как ИДЕ может автоматически генерить тесты?

[Lifewalker]

Не уходите от вопроса. Я спросил, с точки зрения Питонового программиста, на котором операторе завершился цикл? Ошибка интерпретатора лишь констатирует факт несоответствия отступа одному ему известным критериям. Для человека они могут быть не очевидны или даже не видны ввиду ряда причин.

Признаться, я не помню, как Питон ведёт себя, если вдруг встречает в выражении не объявленную переменную. Если останавливается с ошибкой, то это полбеды. А если он её в этот момент создаёт, вот это полная бредятина Так можно договориться до чёрти чего.

Одно дело иметь возможность навтыкать проверки. Другое дело не иметь возможности их не натыкать - ощущаете разницу?

С юнит-тестами умеют работать ВижуалСтудия (точно), Нетбинс (точно), Еклипс (кажется). Попробуйте сами, тут писать нет смысла.

[$oft]

как Питон ведёт себя, если вдруг встречает в выражении не объявленную переменную. Если останавливается с ошибкой, то это полбеды. А если он её в этот момент создаёт, вот это полная бредятина Так можно договориться до чёрти чего.

В php не нужно объявлять переменные..
$parametr = "Hallo world";

$parametr - переменная.. можно её написать в любом месте кода, не определяя её предварительно. Она автоматически создается и присваивается ей значение и это не бред и проблем не возникает. Главное не повторять название одной переменной в пределах одной функции или в пределах области видимости, иначе при одинаковых названиях переменных одна перепишет другую. Я думаю ни у кого не возникало подобных проблем, букв в английском алфавите достаточно.

[Обедающий философ]

Признаться, я не помню, как Питон ведёт себя, если вдруг встречает в выражении не объявленную переменную. Если останавливается с ошибкой, то это полбеды. А если он её в этот момент создаёт, вот это полная бредятина Так можно договориться до чёрти чего.

Ну вот она, кошкин ёж, сила интерактивного режима! Вы как человек, измученный бейсиком, панически боитесь интерактивного режима, посему вынуждены гадать об ответах на такие простейшие вопросы. Тогда как в интерактивном режиме это выясняется за две секунды:

Код: [Выделить]

In [6]: a=q
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

/home/wormball/<ipython console> in <module>()
То бишь ежели мы пытаемся узнать значение необъявленной переменной q, интерпретатор нам говорит, что так делать нельзя, и все счастливы. А ежели мы присвоим значение необъявленной переменной, то она объявится - собственно, это штатный способ объявления переменных. И что вам здесь не нравится?

Не уходите от вопроса. Я спросил, с точки зрения Питонового программиста, на котором операторе завершился цикл? Ошибка интерпретатора лишь констатирует факт несоответствия отступа одному ему известным критериям. Для человека они могут быть не очевидны или даже не видны ввиду ряда причин.

Ну вот давайте я вас спрошу - где остановится программа на паскале, коли в ней написать a=&b+++++&c? А когда вы мне скажете, что она даже не запустится, я вам скажу - не уходите от ответа. Вот здесь то же самое. Определение с ошибкой просто не исполнится. При скармливании файлов, насколько я помню, происходит то же самое - выполняются все определения до того, в котором кроется ошибка. Опять же, ежели в этом возникает сомнение - это можно проверить за две секунды. Ежели некоторому человеку это не очевидно и он при этом называет себя питоновым программистом - он, как говорится, сам дурак.

Одно дело иметь возможность навтыкать проверки. Другое дело не иметь возможности их не натыкать - ощущаете разницу?

Ага, ощущаю. Только вот я сомневаюсь, что есть формальные средства определения того, что проверка надёжна. А коли так, то все эти обязательные проверки непременно будут скатываться к ситуации "лишь бы отвязались". Как, например, есть обязательная справка из поликлиники, а люди вместо того, чтобы проходить врачей, платят некоторую сумму и получают готовую справку.

С юнит-тестами умеют работать ВижуалСтудия (точно), Нетбинс (точно), Еклипс (кажется). Попробуйте сами, тут писать нет смысла.

Это слишком долго, к тому же я явы не знаю. Лучше вы своими словами расскажите.

[blindvic]

При скармливании файлов, насколько я помню, происходит то же самое - выполняются все определения до того, в котором кроется ошибка.

Если ошибка синтаксическая - он не захочет выполнять весь файл

[$oft]

При скармливании файлов, насколько я помню, происходит то же самое - выполняются все определения до того, в котором кроется ошибка.

Если ошибка синтаксическая - он не захочет выполнять весь файл

Он должен указать строку ошибки... Какая бы ошибка это не была.

[Обедающий философ]

Ну так он и указывает. В чём проблема-то?

[$oft]

Ну так он и указывает. В чём проблема-то?

Проблем тогда нет. Тогда я не понял в чем суть спора? и как спор относится к сабжу

[Обедающий философ]

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

Кстати говоря, википедия говорит, что бейсик 30-летней давности был чудовищным языком, в отличие от бейсика, скажем, двадцатилетней давности. http://ru.wikipedia.org/wiki/%D0%91%D0%B5%D0%B9%D1%81%D0%B8%D0%BA Из чего делаем вывод, что чудовищность и интерпретируемость слабо связаны между собой.

[kalex747]

C++ с седьмого класса! Ах... Я 9, а у нас даже Паскаля ещё не было. Ответ на вопрос: Паскаль. Простой и понятный язык, сам с него начинал.

[Упс]

Кстати говоря, википедия говорит, что бейсик 30-летней давности был чудовищным языком

Да так уж и чудовищным. Язык как язык, тем более что 30-летней давности.