Здравствуйте, Джеффри, Вы писали:

Д>Здравствуйте, ksandro, Вы писали:

K>>Чувствую себя старым... Народ уже забыл что такое Delphi...
K>>А ведь когда-то именно для паскаля появилась самая крутая IDE. Можно сказать первая IDE в современном понимании (VB не считается). И именно на паскале проще всего было писать оконные приложения под винду...

Д>ТС предлагает использовать Паскаль 5.5 / Турбо Паскаль для обучения — так что мой комментарий относится к этой версии.
Ок, извиняюсь, похоже я невнимательно прочитал, подумал, что это все относится к языку Паскаль вообще.

Д>А насчет Делфи — тебе сейчас расскажут, что он прививает плохой стиль программирования, т.к. люди пишут код в обработчиках событий, вместо того, чтобы думать о правильной композиции программы!!!
Ну, если хотите писать ГУИ окошками и кнопочками то в любом случае придется обрабатывать события от этих самых кнопочек, никуда от этого не деться. Дельфи не заставляет писать бизнес логику непосредственно в обработчике. Но соглашусь, студенты, научившись кидать кнопочки на форму сразу считали себя крутыми программистами.

Д>А так из реальных недостатков — он вроде платный был раньше? не помню была раньше какая-то бесплатная education / developer версия?
Во времена самой большой популярности Дельфи в бывшем СССР это мало кого волновало вообще.

Здравствуйте, netch80, Вы писали:

S>>Да, но если сказать, давайте учить Бейсик в размере 1995 года, вой же будет ещё больше, не так ли?

N>Так, всё так. Вот потому надо смотреть на что-то современное. При этом язык должен как минимум:

N>1. Не требовать заката солнца вручную там, где сейчас все предоставляют современные возможности. Это относится, например, к типу map (dictionary, hash — где как зовётся), или к базовым возможностям дженериков; возможность объявить const на значение переменной...

В школе, хэштаблица? Нет.

N>2. Позволять умолчательную обработку ошибок на случай "всё хорошо" и её замену на явную, где это надо, вместо полного вылета. И минимум игнорирования, в идеале по умолчанию должно проверяться и ловиться всё.

N>3. Позволять форсировать типизацию даже выше стандартной статики (из банальностей — что-то в духе type body_temperature = 34.0 .. 42.0).

При учёбе? Можно просто избегать задач, где это было бы нужно.

N>4. Или должен форсировать стиль начиная с отступов (Python, Nim), или идти со встроенными средствами проверки и форсирования (включая режим в IDE).

Да.

N>5. Иметь обширную стандартную библиотеку (типа: тот же sort() должен быть; писать самому, конечно, хорошо для учёбы, но постоянно таскать за собой такую реализацию — нуегона) и репозиторий модулей на расширенные случаи (вплоть до чего-то типа CORBA клиента, не к ночи будь сказано).

Какие в школе расширенные случаи? Даже сортировка... написали один раз сортировку пузырьком, и достаточно. Больше она нигде в школьной программе не нужна, по крайней мере в той школьной программе, которой меня учили. А школьная программа, по которой меня учили, была слишком сложная и так, оттуда бы ещё половину выкинуть.

Здравствуйте, netch80, Вы писали:

N>Да. Потому что
N>1) лучше, когда синтаксические средства группировки заметно выделяются формой, чем сливаются с другими словами и идентификаторы.
N>2) например, есть штатные средства перейти на противоположную скобку (любого вида) в каком-нибудь vim, но с begin/end это становится в разы сложнее. Учить редакторы фолдить тоже усложнение.

Ну кого, нафиг, фолдить? Школьная программа должна влезать на тетрадный лист в клетку, 40 строк. Ну, в крайнем случае, два экрана — 50 строк. В ней нет смысла ничего фолдить. Это школа, а не курсы молодого бойца.

Здравствуйте, AlexRK, Вы писали:

ARK>Ряд современных языков не имеет Ц-подобного синтаксиса — Rust, Swift, Kotlin, Scala. В общем, спорный момент.

Не флейму ради, но спрошу — а разве у этих языков не С-подобный синтаксис? Про Rust прямо так пишут, Kotlin и Scala вроде как расширения Java — у нее же С-подобный синтакс? Также Swift идет от Objective-C...

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

Д>>Если человек не будет профессионально программировать, может быть все таки выучить что-то более прикладное? Например, Питон или тот же VBA для продвинутой работы с Эксель.
ARK>За этим надо идти в ПТУ, а не в ВУЗ.

Зачем сразу ПТУ? Если мы, например, говорим о школе или не-программерской специальности в ВУЗе, вопрос — нужно ли учить таким людям основы программирования? И если нужно (я склоняюсь к этому), то должны ли они учить их на неком абстрактном языке, который позволит получить им правильную алгоритмическую базу и усвоить правильные академические концепции (но которые скорей всего лягут мертвым грузом сразу)? Или учить в облегченном варианте, но с прицелом на то, чтобы им было их легче применить на практических задачах?

Здравствуйте, Sharowarsheg, Вы писали:

N>>1. Не требовать заката солнца вручную там, где сейчас все предоставляют современные возможности. Это относится, например, к типу map (dictionary, hash — где как зовётся), или к базовым возможностям дженериков; возможность объявить const на значение переменной...
S>В школе, хэштаблица? Нет.
Реально наблюдал, как дети это использовали. Я помогал вести летний лагерь, где дети учились программировать (роботов) на Питоне. Так вот питоновский хэш все поняли сразу — он вполне очевиден.

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

C>Почему:
C>Говоря двумя словами: потому что в Паскале минимум неоднозначности синтаксиса.

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

Здравствуйте, Александр Кузнецов, Вы писали:

АК>Стесняюсь спросить, а зачем "вы" пишите такие конструкции в реальной жизни? "Вам" нравится, когда к "вам" приходят люди для вдумчивой беседы

Проблема в том, что не приходят. К строителям ещё могут придти, к медикам. К электрикам. А к программистам — нет.

Здравствуйте, Слава, Вы писали:

АК>>Стесняюсь спросить, а зачем "вы" пишите такие конструкции в реальной жизни? "Вам" нравится, когда к "вам" приходят люди для вдумчивой беседы

С>Проблема в том, что не приходят. К строителям ещё могут придти, к медикам. К электрикам. А к программистам — нет.

Ну так это проблема не языка, а отсутствия процессов. Конкретно процесса code review. То, что в Паскале нельзя написать конкретно данную конструкцию не говорит о том, что в нём нельзя написать 100 других.

Здравствуйте, AlexRK, Вы писали:

C>>В Паскале массивы — это нечто магическое (есть синтаксис динамических массивов, но тоже странный), а в С сразу всё становится понятно при работе с арифметикой. Такое же слышал и от других людей.
ARK>А в Го массивы, хеши, каналы — это не магическое, не? Синтаксис не странный?
Ну так я и не предлагаю Го как язык для обучения.

Здравствуйте, Cyberax, Вы писали:

S>>В школе, хэштаблица? Нет.
C>Реально наблюдал, как дети это использовали. Я помогал вести летний лагерь, где дети учились программировать (роботов) на Питоне. Так вот питоновский хэш все поняли сразу — он вполне очевиден.

Летний лагерь, где были (условные) добровольцы, которым было интересно? Для них, конечно, это вполне очевидно. В летнем лагере биологов, где дети учились гербарии делать, это не было бы так легко. Не потому, что дети тупее, а потому, что нафиг им это не нужно. Хештаблицы прекрасны для факультативов и летних лагерей.

C>Тут стоит задуматься, что торайдиционные программы, которые мучают детей массивами, стоит как бы немного пересмотреть.

Да, и массивы выкинуть.

Здравствуйте, netch80, Вы писали:

N>Но программист с этими проблемами C++ обычно не сталкивается — до тех пор, пока не обнаруживает, что A B(C); вдруг стало не тем, чем он хочет — тогда он меняет () на {} и забывает о проблеме.

N>Так что — определитесь, о чём вы. Если о неоднозначностях для парсинга, то вам пора таки обновить своё понимание в этой области. Если для пишущего...

Хм... топикстартер, вроде про обучение программированию писал. Я тоже словосочетания вида «парсинг программного кода», или «синтаксический анализатор» нигде не упоминал. Так что точно не про компиляторы.

N>вот честно говоря, написать сложную конструкцию серьёзнее, чем a (*b)()[3]; без бутылки будет трудновато. Так что C/C++ и в этом смысле ой.
Не знаю. Я в с/с++ ном коде извращения видел только в трёх случаях:
1. Жёсткая оптимизация кода (в которой каждый чих был жёстко обоснован)
2. Криворукие студенты после ВУЗов, пока им ещё руки не выпрямили (но это для любого языка характерно)
3. Статьи «как всё плохо» на условном хабре.

Возможно, есть ещё какие-то варианты, но я только с этими тремя сталкивался.

Здравствуйте, kov_serg, Вы писали:

C>>Какой смысл даёт объявление переменных в начале? Для любого современного компилятора это совершенно пофиг.
_>Дело в том что объявление переменных в начале убирает синтаксический шум внутри, видно сколько и какие переменные используются. Появляется дисциплина и порядок.
Ерунда полнейшая.

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

C>>Для программиста не пофиг, так как нельзя с первого взгляда увидеть, где переменная получает значение.
_>Так какие проблемы если так надо можно добавть резервное слово для первого присвоения скажем let. Оно будет единообразно указывать на первое определение.
Ну и нафиг тогда объявление ВООБЩЕ?

C>>Ну и с иммутабельностью по умолчанию оно тоже никак не дружит.
_>С какого перепоя. Компилятору всё равно где объявление. Так что оно будет работать как и работало.
С такого:

let somevar=fn(); // 1st time
let v1="string";
let v2=3.14;
let v3=fn();
if (cond) let v4=1; else let v4=2;
...
somevar=fn(); // 2nd time

Ну и где больше шума?

Здравствуйте, netch80, Вы писали:

C>>В Паскале массивы — это нечто магическое (есть синтаксис динамических массивов, но тоже странный), а в С сразу всё становится понятно при работе с арифметикой. Такое же слышал и от других людей.
N>Я имею в виду то, что уже просто var x: ^integer; это лучше, чем int *x; и чем сложнее конструкция, тем легче её читать в таком виде.
В С есть удобный разыменователь: ptr->x, в Паскале его нет.

N>Для динамических массивов, да, методы работы совершенно другие — указатель под капотом, а в явном виде зовёшь setlength и дальше работаешь как с обычным. Получается где-то так же, как std::vector<тип>& в C++.
Да, но только это всё скрыто магией. Совершенно непонятно причём там указатели.

N>Фокус в виде a[i] == i[a] == *(a+i) там не одобряют в чистом виде. Но в борландовской линии, по-моему, писать явно (a+i)^ было можно и нужно, если тебе в явном виде передали unsafe-указатель (хоть он так и не назывался).
Ну вот потому С как раз очень помогает понять указатели, в отличие от Паскаля. С точки зрения промышленного программирования с указателями в С — полная катастрофа с безопасностью, но для обучения как раз идеально.

Здравствуйте, Cicero, Вы писали:

C>Очень часто это слышу: Паскаль(иногда конкретизируют: Turbo Pascal) не подходят для обучения программированию.
C>Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!

Те, кто говорят, что "не подходит", обычно имеют в виду, что не подходит для процесса ускоренной подготовки востребованного рынком условного г-кодера, который из-за парты и сразу "на галеру". И они правы, т.к. в этом процессе Паскаль действительно лишнее звено, почти бесполезная трата времени. Для изучения же собственно программирования как дисциплины Паскаль вполне подходит.

С другой стороны, те, кто говорят, что Паскаль "хорош" и для первого языка подходит идеально, это как правило те же, у кого Паскаль был первым или первым "серьёзным" языком. То есть проявляется эффект "первой любви" (Я тоже из их числа, так что делайте скидку на это Недостатки у него безусловно есть, их уже называли выше. В зарубежных вузах на соответствующих курсах уже давно используют Modula 2; а сейчас наверное уже что-то и более современное.

P.S. Аргумента "должен быть непременно C-подобный синтаксис" я принять не могу. Если ты изучаешь программирование глубоко и основательно, нужно изучать языки с разным синтаксисом; и научиться не путаться, переходя от одного к другому.

Здравствуйте, wildwind, Вы писали:

W>Для изучения же собственно программирования как дисциплины Паскаль вполне подходит.
Не подходит. После Паскаля приходится потом долго вправлять моск в правильную сторону.

W>В зарубежных вузах на соответствующих курсах уже давно используют Modula 2; а сейчас наверное уже что-то и более современное.
В "зарубежных курсах" Паскаль давно похоронили. В качестве первого языка чаще всего берут Питон, затем С/С++/Java.

Здравствуйте, Sharowarsheg, Вы писали:

N>>Да. Потому что
N>>1) лучше, когда синтаксические средства группировки заметно выделяются формой, чем сливаются с другими словами и идентификаторы.
N>>2) например, есть штатные средства перейти на противоположную скобку (любого вида) в каком-нибудь vim, но с begin/end это становится в разы сложнее. Учить редакторы фолдить тоже усложнение.

S>Ну кого, нафиг, фолдить? Школьная программа должна влезать на тетрадный лист в клетку, 40 строк. Ну, в крайнем случае, два экрана — 50 строк. В ней нет смысла ничего фолдить. Это школа, а не курсы молодого бойца.

В среднем школьном возрасте уже пора заниматься чем-то реальным. В старшем и вузе — тем более. Обучение программированию не означает необходимости гонять гномиков по экрану и считать простые числа. А понимание того, что твои 30 строчек помогли проекту на пару миллионов строк, морально подстёгивает профессиональный рост лучше, чем тупые отметки "отлично".

Здравствуйте, Sharowarsheg, Вы писали:

S>>>Да, но если сказать, давайте учить Бейсик в размере 1995 года, вой же будет ещё больше, не так ли?

N>>Так, всё так. Вот потому надо смотреть на что-то современное. При этом язык должен как минимум:

N>>1. Не требовать заката солнца вручную там, где сейчас все предоставляют современные возможности. Это относится, например, к типу map (dictionary, hash — где как зовётся), или к базовым возможностям дженериков; возможность объявить const на значение переменной...

S>В школе, хэштаблица? Нет.

Это ваша религия говорит? И она хоть как-то это пытается обосновать?
Чем плохо иметь и использовать тип данных "хранилище ключ-значение"?

N>>2. Позволять умолчательную обработку ошибок на случай "всё хорошо" и её замену на явную, где это надо, вместо полного вылета. И минимум игнорирования, в идеале по умолчанию должно проверяться и ловиться всё.

N>>3. Позволять форсировать типизацию даже выше стандартной статики (из банальностей — что-то в духе type body_temperature = 34.0 .. 42.0).

S>При учёбе? Можно просто избегать задач, где это было бы нужно.

То есть старательно избегать реальных задач, вместо этого ограничиваясь какими-нибудь "сумма чётных элементов в нечётных позициях массива"?

N>>4. Или должен форсировать стиль начиная с отступов (Python, Nim), или идти со встроенными средствами проверки и форсирования (включая режим в IDE).

S>Да.

Ну хоть что-то "да"

N>>5. Иметь обширную стандартную библиотеку (типа: тот же sort() должен быть; писать самому, конечно, хорошо для учёбы, но постоянно таскать за собой такую реализацию — нуегона) и репозиторий модулей на расширенные случаи (вплоть до чего-то типа CORBA клиента, не к ночи будь сказано).

S>Какие в школе расширенные случаи? Даже сортировка... написали один раз сортировку пузырьком, и достаточно. Больше она нигде в школьной программе не нужна, по крайней мере в той школьной программе, которой меня учили. А школьная программа, по которой меня учили, была слишком сложная и так, оттуда бы ещё половину выкинуть.

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

Здравствуйте, Александр Кузнецов, Вы писали:

N>>Но программист с этими проблемами C++ обычно не сталкивается — до тех пор, пока не обнаруживает, что A B(C); вдруг стало не тем, чем он хочет — тогда он меняет () на {} и забывает о проблеме.
N>>Так что — определитесь, о чём вы. Если о неоднозначностях для парсинга, то вам пора таки обновить своё понимание в этой области. Если для пишущего...
АК>Хм... топикстартер, вроде про обучение программированию писал. Я тоже словосочетания вида «парсинг программного кода», или «синтаксический анализатор» нигде не упоминал. Так что точно не про компиляторы.

OK, определились. Но всё равно в этом случае будет заметная часть специфических "дети, это невозможно понять, это надо запомнить".

Например, когда пишешь что-то вроде for (int i = 0; i < 10; ++i) сразу несколько граблей для новичков, которые требуют вначале тупо зазубрить и свыкнуться:
— почему надо писать раздельные условия, а нельзя просто "от 0 до 9"?
— почему одну и ту же переменную три раза и не ошибиться (j вместо i, ii вместо i и т.п.)? (а часто таки ошибаются; при двух циклах рядом уже легко попутать, а при вложенных так вообще профессионалы путают)
— почему надо писать ++i, а не i++, или наоборот? (что тут всё равно — надо ещё понять, почему)
— а условия i <= 9 и i < 10 это одно и то же? (в спокойной обстановке они сами это скажут и посмеются, что кто-то не понимает, но когда сам начинаешь писать, нервы всё сбивают)

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

N>>вот честно говоря, написать сложную конструкцию серьёзнее, чем a (*b)()[3]; без бутылки будет трудновато. Так что C/C++ и в этом смысле ой.
АК>Не знаю. Я в с/с++ ном коде извращения видел только в трёх случаях:
АК>1. Жёсткая оптимизация кода (в которой каждый чих был жёстко обоснован)
АК>2. Криворукие студенты после ВУЗов, пока им ещё руки не выпрямили (но это для любого языка характерно)
АК>3. Статьи «как всё плохо» на условном хабре.

АК>Возможно, есть ещё какие-то варианты, но я только с этими тремя сталкивался.

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

Здравствуйте, AlexRK, Вы писали:

N>>Ну я вообще считаю, что {} надо делать обязательными везде. Речь-то шла о существующем.
ARK>Существующая ситуация состоит в том, что блок repeat-until не является уникальным для паскаля.

Ну да, с третьей-четвёртой попытки нашли случай, когда ему есть эквивалент

N>>Много функций особых. Есть вложенные. Есть всякие interrupt handlers или обработчики сигналов.
N>>Есть вызываемые при старте и стопе программы. Есть функции тредов.
ARK>По-моему, все эти функции с точки зрения языка особенными не являются. Например, обработчик прерывания — чем он особенный?

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

N>>Что, всем особый синтаксис?

ARK>Если с точки зрения языка функция является особенной — то лучше ей дать отдельный синтаксис. Этот подход применяется и не только в учебных языках (см. async-await), ну а уж в учебных сам б-г велел.

Ну вот и дают, например, простановкой атрибутов (ранее — спец. ключевыми словами).
А зачем при этом менять метод парсинга?

N>>Для рантайма, кстати, main() совершенно стандартна, и все описанные спецтребования, во-первых, только для hosted режима (во freestanding main() может и не быть, или она может иметь другие свойства), а во-вторых, всё, что ему нужно — чтобы она была main, а не _Z4mainipv или как оно там будет звучать.
N>>Хотя конкретный компилятор может сделать из неё _MAINQQ$$, если ему так нравится

ARK>Текст программы читает человек, а не рантайм.

И пишет тоже, представь себе. И он вполне способен написать и увидеть слово main.

N>>После Паскаля этого никто не повторял. Даже в Ada нет такого, хотя уж в нём строгостей нагнали. Так что могу считать подтверждённым, что этот бред никому не нужен.

ARK>Какие именно языки, предназначенные для обучения, были созданы после паскаля? То, что в промышленных или любительских "никто не повторял" — это не показатель.

Посмотри сам в список. Я из более-менее известного вижу:
— Python (хм, он начинался как учебный?) В нём тоже нет особого синтаксиса для main; есть факт, что стандартным интерпретатором из основной программы выполняется код уровня модуля, но это именно стиль интерпретации по умолчанию, а не обязательное правило.
— Рапира — паскалеобразная — нет пресловутой точки.
— Haskell — нет точки или аналога.

N>>По себе и не сужу, и всех не сужу, пытаюсь оценить конкретно тебя и этот код. Пример можно?
ARK>if ((a > 3) && (b == 4))
N>>А ассоциативность ты тоже явно помечаешь? a+b+c нельзя, можно только (a+b)+c?
ARK>Ассоциативность во всех случаях, с какими я имел дело, всегда слева направо. Поэтому не помечаю. Но если бы пришлось писать код, где ассоциативность иная (всякие там сложения вещественных чисел в чувствительных к этому алгоритмах) — то обязательно бы пометил.

Для "иных" пишут, считаем, все грамотные. А что в случае x = a + b * c; ?

Здравствуйте, Cyberax, Вы писали:

C>>>В Паскале массивы — это нечто магическое (есть синтаксис динамических массивов, но тоже странный), а в С сразу всё становится понятно при работе с арифметикой. Такое же слышал и от других людей.
N>>Я имею в виду то, что уже просто var x: ^integer; это лучше, чем int *x; и чем сложнее конструкция, тем легче её читать в таком виде.
C>В С есть удобный разыменователь: ptr->x, в Паскале его нет.

C: obj.x, ptr->x
Pascal: obj.x, ptr^.x

о скобках в сложных случаях надо думать у обоих (хотя (*a)->b превращается в a^^.b, а *a->b — в a^.b^, я что-то не соображу сейчас случай посложнее).

тебя "^." настолько смущает синтаксически? Форма стрелки направо критична?

N>>Для динамических массивов, да, методы работы совершенно другие — указатель под капотом, а в явном виде зовёшь setlength и дальше работаешь как с обычным. Получается где-то так же, как std::vector<тип>& в C++.
C>Да, но только это всё скрыто магией. Совершенно непонятно причём там указатели.

Как это зачем? Указатель на выделенную динамическую область. Или ты о чём?

N>>Фокус в виде a[i] == i[a] == *(a+i) там не одобряют в чистом виде. Но в борландовской линии, по-моему, писать явно (a+i)^ было можно и нужно, если тебе в явном виде передали unsafe-указатель (хоть он так и не назывался).
C>Ну вот потому С как раз очень помогает понять указатели, в отличие от Паскаля.

Я бы не сказал, что возможность a[i] === i[a] тут как-то существенно помогает

C> С точки зрения промышленного программирования с указателями в С — полная катастрофа с безопасностью, но для обучения как раз идеально.

Не-а. Чтобы понять простую идею "указатель это адрес", это всё не нужно.
Чтобы понять арифметику указателей — тоже. Её по любому надо явно объяснить, и этого достаточно.