OberonCore

Под скриптовыми подразумеваются языки с динамической типизацией?

Нет, я имею в виду интерпретацию.

P.S. я дополнил предыдущее сообщение.

Круто.

Слишком сложные проверки там с этими контрактами понаворотили....
Это не просто ASSERT - вот и прокололись на эффективности.

ASSERT'ы тоже можно так расставить, что будет тормозить в разы. В ББ разница между включенными/выключенными проверками не так заметна, потому что оптимизация со стороны компилятора отсутствует как класс Поэтому включенным ассертам ставить палки в колеса некому Впрочем это все в копилку различий в подходах: "компилятор для человека" vs "человек для компилятора".

Ну прям "человек для молотка" или "молоток для человека".

Думайте сами, решайте сами - здоровый "чёрный ящик", непонятно как работающий и - самое главное! - написанный тем, кому не доверяешь (тем, кому можно доверять, надо платить нехреновые деньги - как вот за QNX, например...) - тоже малоприятного иметь... Боком выходит рано или поздно )))

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

Отвык я от такого.

Ужасы какие рассказываете... Я использую питон каждый день. Падения видел только на стресс-тестах, грузящих .NET assembly.

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

Это в другую копилку: насколько трудно молодежи с коротким горизонтом опыта оценить Принцип Калашникова.

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

Мысли о Python.
По роботе имею с ним немного дело.
Язык с низким барьером входа.
Как результат простые проги (скрипты) пишутся довольно легко.
Но язык сложный, навороченный -- все фитчи очень сложно осилить (но они и не нужны для скриптов на 100 строчек).
Проблемы начинаются с большими программами, скажем с тысяч строчек, написанные не Вами.
Понять код, в котором нет типов, еще сложнее, чем осилить templates в C++.

При не тривиальных случаях необходимо понимание инструмента, а разобраться как оно работает невероятно сложно -- сложность скрывает реализацию.
Как пример: "пробег по списку до конца" всегда заканчивается исключительной ситуацией.
Т.е. оказывается конец списка -- это "что то невероятное" в Питоне!
Пока код примитивный -- это незаметно (for elem in list:...).
Но в нетривиальных случаях количество catch'ев может превзойти количество if'ов.
Вот такой нетривиально сложный гнилой фундамент.

Если сравнивать с C++, то Python действительно может сгодится как закрытие дыр C++.
Но совершенно однозначно: неоправданная сложность и плохая читабельность их роднит.

Вот это - да! Это - не шутка? Я просто Питон не знаю, но даже не представляю, в каком навороченно-неординарном подходе к проектированию, такое по трезвости в голову могло прийти?!
ЗЫ Это всё равно, как с детства волновавший меня вопрос, почему при введении буквы для звукосочетания "йо" решили ставить две точки над литерой "е", а не над "о"... Ну точно академия после бодунища вопрос обсуждала!... Или женщина предложила...

Исторически когда-то там был звук е, и буква ставилась соответственно.
В некоторых позициях под ударением в разговоре превратилось в йо, но в словоизменении всё равно там чередуется древнее е (черта--чёрточка, весна--вёсны).
А отмечать такие случаи точечками придумал Карамзин.

Как лодку назовёшь - так и поплывёт Язык Питон, например, назвали в честь цирка Монти Пайтона(Monty Python), а не в честь большой змеи

Добавлю: Летающего цирка! (Monty Python's Flying Circus)

А можно пример?

цикл for
по определению эквивалентен (while+try-except+break):

попробуйте ЭТО переписать через while без break.

Теперь представьте, что необходимо организовать поиск по списку (WHILE (list # NIL) & ~found DO... list := list.next END)
Либо for+if+break либо если без break, to while+try-except+if+if+ -- короче ну очень заворочено.
А если поиск не тривиальный?!

Пока все ваши схемы примитивны, это может не сильно напрягать.
Но в общем случае не совсем понятно в что это выльется.

Чужой код, что я видел содержит очень большое количество операторов break и try-except.
Легкость написания приводит к огромным функциям.
Сами по себе break'и тоже ведут к увеличению тела циклов.
Последнее замечание -- относится не только к Python, но именно в Python break'ов слишком много!

PS Конечно можно опять спихнуть все на программиста, но язык поощряет "такое городить".
PPS На простых задачах обработки/конвертации текста таких эффектов не замечал -- все схемы циклов были FOR EACH.

Утверждение и так вполне правильное.

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

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

А Калашников и не знает, что кое-кто упорно пытается поставить его знак качества на не самый удачный ЯП. Нехорошо.