Re: Чем плох Паскаль?
От: AlexRK  
Дата: 13.06.19 16:45
Оценка: 4 (2) +11 -1
Здравствуйте, Cicero, Вы писали:

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

C>Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!

Паскаль ничем не плох. Он прост и строг, для начального обучения программированию это очень хорошие качества.
Re: Чем плох Паскаль?
От: elmal  
Дата: 13.06.19 18:53
Оценка: +7 -3 :))
Здравствуйте, Cicero, Вы писали:

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

C>Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!
Аргументы:
1) Многословный. Чтобы написать простейшую вещь, нужно очень много кода;
2) Нет нормального современного IDE. Нужны средства автоматического рефакторинга, удобной навигации по коду, поиск зависимостей, легкие быстрые переименования, выделения функции, метода, интерфейса, переменной и т.д;
3) Низкоуровневый. Нет нормальных удобных библиотек. Все пиши на низком уровне, сам, на массивах и указателях. В итоге имеем, что за неимением нормальных библиотек, новички для решения простейших задач городят тормозные громоздкие спагетти велосипеды, с квадратичной сложностью вместо константной;
4) Не поддерживаются концепции, которые современные программисты должны знать. Функциональная парадигма, распараллеливание, конкуррентность, асинхронность, реактивное программирование, итераторы, метапрограммирование — сейчас это база, которую нужно знать даже новичкам. И легче всего это делать сверху вниз, сразу прививая нормальный стиль.
5) В современном мире паскаль прививает крайне хреновый стиль программирования. Только недавно сделали возможность объявлять переменные по месту использования;
6) Куча граблей на ровном месте. Юникоды и т.д, приходится воевать с тем, о чем в других языках уже давно не задумываешься.
7) Трудности с написанием нормального современного UI. Набросать формочку и прямо в обработчике кнопки фигачить всю логику — это ни хрена не современный UI. Формируется по умолчанию такой стиль у новичков, что потом их либо хрен будут брать на работу, либо они потратят много времени и сил и переучатся практически с нуля. Сил приходится прикладывать настолько много, что быстрее полного нуля научить заново, чем переучивать того, кто говнокодил десятилетиями. Полюбуйтесь на нашего главного православного, его именно паскаль сгубил, его теперь хрен переучишь, если он не научился программировать на юниорском уровне за 20 лет, хрен он когда научится теперь.
8) Оторванность от современных реалий. Нет нормальной литературы, современных библиотек на все случаи жизни. Вот если тебе нужно какую нидь кластеризацию k means по быстрому сделать, чтоб на видюхе считалось — что, будешь с нуля писать все?
9) Новичкам нужно быстро что то сделать чтобы было красиво. Графику подрубить быстро, текстурочку, чтоб со звуками и т.д. Быстро и просто не получится даже на продвинутых паскалях. Да, будет проще, чем в 80-е годы, но много геморройнее, чем даже на JavaScript. На котором всякие 3d крайне легко делать.
10) Community. Всякие паскали уже все давно забыли как страшный сон. Задашь какой вопрос на форуме — хрен тебе кто ответит, это давно уже не актуально. Будешь на грабли наступать самостоятельно и абсолютно бессмысленно.

Хватит. Язык был неплох для обучения в 80-х годах. Какая то применимость была в 90-е. Уже в двухтысячном от него нужно было держаться как можно дальше, появились языки много лучше. В 2019-м даже мысли не может быть такое использовать для обучения. Еще б бейсик ранних 80-х бы вспомнили, с переменными f1 и строковыми вида $b5, с ограничениями на максимальную длину переменной, с редакторированием по строчкам, со всякими rename, gosub, goto . После таких ужасов прямой путь на ассемблер, чтоб на ассемблере не казалось все так страшно. Вот только ниша ассемблера в современном мире весьма узка, и начинать с него нет никакой необходимости.
Re[2]: Паскаль неплох, но Javascript лучше
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 04.07.19 11:59
Оценка: +4 :))) :))) :))
Здравствуйте, C0x, Вы писали:

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

1) Матерный вообще не требует никакой тетрадки, достаточно иметь: забор и маркер.
2) Легкость получения первых результатов: берем любую поверхность, пишем на нем "х.й" и радуемся.
3) Куча примеров крутых выражений в интернете в том числе в летсплеях игр.
4) Школьники смогут делиться результатами своих работ мгновенно со всем миром, публикуя мат в интернете.
5) Язык современный и весь веб на нем держится.
Re: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 13.06.19 19:26
Оценка: 4 (3) +6
Здравствуйте, Cicero, Вы писали:

C>Почему:

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

Это шутка такая, да?

Точку с запятой можно ставить перед end и после begin, а можно не ставить. Но нельзя — перед else. Очень логично, да.

Одиночные предложения можно заворачивать в begin-end, а можно не заворачивать. Сначала рассказываем, как ставить одно предложение после if или внутри while, а потом переучиваем на то, что их надо ставить чуть ли не всегда.

Зато repeat — until почему-то само образует блок. "Дети, это невозможно понять, это надо запомнить".

Всякие read/writeln могут иметь первым параметром файл, а могут и не иметь. Следите за руками и не удивляйтесь, что вообще перегрузки функций нет, а тут она почему-то есть. Что не позволено простому быку, позволено Юпитеру. Кстати, что это за синтаксис такой write(a:3:2), и почему он работает только тут?
Ещё и функции с переменным числом параметров вдруг самозародились? (Я про Паскаль, а не про всякие поздние Delphi.)

Синтаксис цикла — for i := 1 to 10, например. Сначала ":=" несловесной лексемой, затем почему-то "to" — словесной. А назад — downto. Кстати, если я хочу шаг 2? "Петрику, слухай пісню про комбайн"?

if a=1 or b>0... ой, не то получилось. Надо подвыражения в скобки заключать, потому что у or почему-то приоритет выше.

Идентификаторы регистронезависимые. Потом долго пытаешься понять, почему boo и Boo начали неожиданно путаться. И не надо рассказывать, что плохое именование. Тот, кто только учится, в своём коде не успевает за эти следить.

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

C>ИМХО это научит контролировать код более строго.


Сказки-то какие, страсть

Чесслово — по сравнению с Паскалем даже Go лучше. И вот там, кстати, настоящая осмысленная строгость (порой даже слишком).

Вирт, кстати, часть этих огрехов Pascal исправил, создав Modula. Но упёртым баранам из всяких Borland было на это плевать.
Re: Чем плох Паскаль?
От: Klikujiskaaan КНДР  
Дата: 13.06.19 15:14
Оценка: +4 :))) :))
Здравствуйте, Cicero, Вы писали:

C>Почему:

C>Говоря двумя словами: потому что в Паскале минимум неоднозначности синтаксиса.
C>ИМХО это научит контролировать код более строго.

В лиспе еще меньше + SICP и HTDP.
А паскаль не нужен по причине того, что после него надо учить другой ЯП для подключения пупса к станку.
Re[3]: Чем плох Паскаль?
От: TMU_1  
Дата: 13.06.19 15:48
Оценка: +8
K>>для подключения пупса к станку.
С>Простите, что?



Имеется в виду, очевидно, что паскаль — не промышленный язык. Имеется в виду, очевидно, что после школьного курса джавы, к примеру, человека можно было бы ставить к станку (здесь сатанинский смех).
Re: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 13.06.19 19:00
Оценка: +4 -3 :)
Здравствуйте, Cicero, Вы писали:

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

C>Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!
Самый сильный аргумент — он просто уродливый.

Если изучать программирование, то есть две цели:
1) Общеобразовательная.
2) Обучение для программистов.

Если цель просто общеобразовательая, то Паскаль тупо переусложнён. В нём есть типы, но нет простых вещей типа удобного вектора и хэш-карты. Есть непонятные ограничения типа объявления переменных в начале, невнятный файловый ввод/вывод и т.п.

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

Для обучения программистов всё вышесказанное, плюс к этому добавляется железный барьер — работа с динамическими структурами вообще совсем никакая. Указатели в Паскале придумали какие-то извращенцы. Каких-либо полезных библиотек под Паскаль тоже нет — вывести JPEG-изображение или добавить звук в программу просто не получится.

В современном варианте было бы лучше что-то типа Питона с графической средой. Или как вариант: https://www.apple.com/swift/playgrounds/ — лучшее, что я вообще видел для детей.
Sapienti sat!
Re: Чем плох Паскаль?
От: Джеффри  
Дата: 13.06.19 17:10
Оценка: +7
Здравствуйте, Cicero, Вы писали:

C>Давайте обсудим и выработаем обоснованные аргументы.


Вставлю свои 5 копеек. Кстати, я сам начинал учить программирование с Турбо Паскаля и у меня остались самые теплые воспоминания о нем

Из плюсов:

* Типичный императивный язык программирования, можно и в процедурное, можно и в ООП.
* Простой синтаксис, который позволяет новичку абстрагироваться от некоторых низкоуровневых аспектов (например, работа со строками организована намного проще, чем в С) и сосредоточиться на алгоритмах программы. Но в то же время при необходимости к ним тоже можно обратиться — указатели, динамическое выделение памяти.

Из минусов:

* Не С-подобный синтакс — если человек продолжит дальше учить программирование, ему придется отвыкать от begin/end, case, := и т.д. Не критично, мне в свое время наоборот помогло понять, что синтаксический сахар это одно, а концепции, которые лежат в основе языков — это другое. Но некоторых может раздражать.
* Имижд старого языка и, как уже отмечали выше, его тупиковость. Т.е. если человек продолжит профессионально учить программирование дальше, то ему придется учить "настоящий" язык. Так может лучше начать с С или даже сразу с базового С#, не углубляясь в дебри сразу? Если человек не будет профессионально программировать, может быть все таки выучить что-то более прикладное? Например, Питон или тот же VBA для продвинутой работы с Эксель.
* Нет возможности легко разрабатывать UI, пусть даже и очень простой (Turbo Vision не предлагать). Иногда для ребенка может быть намного интересней сделать программу с окошком и кнопкой, похожую на реальное приложение, чем делать консольную утилиту с выводом в командную строку.
* Наследие MS DOS — не знаю можно ли сейчас вообще легко запустить IDE на новых версиях Виндоус, объяснять почему длина имени файла не может быть больше 8 символов, возиться с кодировками и т.д.
Re: Чем плох Паскаль?
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 13.06.19 17:18
Оценка: +5 -1
Изучая промышленный язык, школьник может понемногу участвовать в интересных проектах и использовать огромную общедоступную базу знаний. Изучая Паскаль, он может только копировать с доски.
Ce n'est que pour vous dire ce que je vous dis.
Re[5]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 15.06.19 13:44
Оценка: +6
Здравствуйте, netch80, Вы писали:


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


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


Только школьники, увлекающиеся химией, биологией, и другими, не менее важными дисциплинами, не заинтересованы ни в профессиональном росте в области программирования, ни в каком-то там проекте на миллион строк. И не надо их никуда подстёгивать, а тем более не надо им в глотку сувать редактор с фолдингом.
Чем плох Паскаль?
От: Cicero www.ya.ru
Дата: 13.06.19 14:54
Оценка: +2 -3
Очень часто это слышу: Паскаль(иногда конкретизируют: Turbo Pascal) не подходят для обучения программированию.
Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!

Давайте обсудим и выработаем обоснованные аргументы.

Во первых нужно конкретизировать:
для обучения где? в общеобразовательной школе? в ВУЗе? в ВУЗе которые готовят именно программистов?
как первый язык программирования? как второй?

Выскажу свое мнение:
Для обучения в школе как первый язык программирования с которым человек встречается Паскаль очень даже подходит.
Причем если не позволяет "железо" более современные версии вполне подойдет и Turbo Pascal 5.5.
На Turbo Pascal вполне можно обучать и элементы ООП.

Почему:
Говоря двумя словами: потому что в Паскале минимум неоднозначности синтаксиса.
ИМХО это научит контролировать код более строго.
O tempora! O mores!
Re: Чем плох Паскаль?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 13.06.19 17:30
Оценка: +5
Здравствуйте, Cicero, Вы писали:

Для изучения нужен язык на котором можно решать реальные задачи. В моем случае сначала был фортран для решения задач по математике и физике, потом бейсик и паскаль на ДВК 2, для задач на кафедре обогащения (руд цветных металлов). Выбор пал на паскаль из-за скорости выполнения и самого языка. Затем турбо-паскаль, Delphi, 1C, C#.
Я это к чему. Просто изучать язык не имеет смысла. Но например TypeScript в составе ангулара или C# в составе Unity или MonoGame
То есть ученик реально видит для чего нужно программирование и заражается им
и солнце б утром не вставало, когда бы не было меня
Отредактировано 13.06.2019 17:33 Serginio1 . Предыдущая версия .
Re[2]: Чем плох Паскаль?
От: AlexRK  
Дата: 13.06.19 17:41
Оценка: +3 -2
Здравствуйте, Джеффри, Вы писали:

Д>* Не С-подобный синтакс


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

Д>* Имижд старого языка и, как уже отмечали выше, его тупиковость. Т.е. если человек продолжит профессионально учить программирование дальше, то ему придется учить "настоящий" язык.


Верно.

Д>Так может лучше начать с С или даже сразу с базового С#, не углубляясь в дебри сразу?


Не лучше. В сишарпе нельзя не углубляться в дебри (пусть даже они там и не такие дебристые, как в Ц++).

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


За этим надо идти в ПТУ, а не в ВУЗ.

Д>* Нет возможности легко разрабатывать UI, пусть даже и очень простой (Turbo Vision не предлагать). Иногда для ребенка может быть намного интересней сделать программу с окошком и кнопкой, похожую на реальное приложение, чем делать консольную утилиту с выводом в командную строку.


В целом да, хотя есть лазарус, вроде в нем лепить можно, но сам не пробовал.

Д>* Наследие MS DOS — не знаю можно ли сейчас вообще легко запустить IDE на новых версиях Виндоус, объяснять почему длина имени файла не может быть больше 8 символов, возиться с кодировками и т.д.


FreePascal работает на любых платформах и полностью совместим с трубопаскалем.
Re[3]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 13.06.19 23:01
Оценка: +1 :))) :)
Здравствуйте, Слава, Вы писали:

C>> работа с динамическими структурами вообще совсем никакая. Указатели в Паскале придумали какие-то извращенцы.

С>Что там не так с указалями?
Совершенно дикий синтаксис, который ни на что не похож. Я начинал учить программирование с Паскали, и так и ниасилил их.

Но после перехода на С всё стало абсолютно кристально понятно сразу же.
Sapienti sat!
Re: Паскаль неплох, но Javascript лучше
От: C0x  
Дата: 03.07.19 07:11
Оценка: +1 -2 :))
Здравствуйте, Cicero, Вы писали:

Лучший язык программирования для обучения сегодня Javascript. Не кидайте в меня сразу тухлыми яйцами, попробую объяснить свою точку зрения

1) Javascript вообще не требует никакой IDE, достаточно иметь: Браузер и Блокнот.
2) Легкость получения первых результатов: Создаем на диске файл hello.html, пишем в нем "<script>document.write("Hello World");</script>" и запускаем.
3) Куча примеров крутых приложений в интернете в том числе html5 игр.
4) Школьники смогут делиться результатами своих работ мгновенно со всем миром, публикуя код в интернете.
5) Язык современный и весь веб на нем держится.
Re[2]: Чем плох Паскаль?
От: elmal  
Дата: 15.06.19 21:26
Оценка: 16 (2) +2
Здравствуйте, scf, Вы писали:

scf>НО — для начального обучениния избыток парадигм вреден. К примеру, вот что входило в мою школьную программу:

scf>- понятие алгоритма
Допустим, но это на любом языке.
scf>- операторы, переменные, типы, условия, циклы
Допустим, но это на любом языке. При этом не хватает циклов вида для каждого, и это в современном мире основной вид цикла. Цикл со счетчиком в современном мире применяется только тогда, когда начинаешь заниматься оптимизацией.
scf>- процедуры, функции
Допустим, но это есть в любом языке.
scf>- структуры данных: массивы, строки, списки, деревья
А вот это в паскале фигово. Удобно работать только с массивами статической длины. Как только нужны динамические массивы — страх и ужас, реально сложно понять, сложный неудобный синтаксис даже по сравнению с Си. Строки — где поддержка юникода, в современном мире без юникода никуда. Списки и деревья — нужно это иметь в стандартной библиотеке.

scf>- алгоритмы: поиск элементов в масивах, обход списков, обход деревьев, двоичный поиск, решение уравнений методом деления пополам

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

scf>- ascii графика (типа распечатать таблицу умножения)

scf>- цветная графика — нарисовать пейзаж, анимация, графики, графики трехмерных функций по алгоритму художника
На паскале это делать умрешь.

scf>- программы не требуют ни `public static void main`, ни хитрого кода инициализации консоли/окна/графики

Угу. uses crt, объявляние program my program и т.д. Все там требуется, причем много больше, чем на скриптовых языках. Реалии таковы, что 99 процентов тех, кого пытались учить паскалю в школе, не понимали ни хрена. Во многих случаев из за синтаксиса, слишком много действий нужно сделать для простейших результатов. Сейчас практически везде все делается гораздо проще.

scf>- простой удобный интерактивный отладчик, мнгновенная компиляция

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

scf>- строгий структурированный синтаксис на английском языке, без лишних сокращений типа фигурных скобок и навязанных идиом типа значимых отступов

Слишком многословный синтаксис. Причем там до хрена нужно именно что учить. Ибо автокомплита нет ни черта.

scf>- строгая типизация

Достаточно много строго типизированных языков, которые во всем лучше паскаля.

scf>- достаточно низкоуровневый, чтобы рассказывать школьникам про байты, биты, непрерывные многомерные массивы и организацию памяти

Рассказывать школьником про байты можно хоть на JavaScript. Как и про многомерные массивы.
Re[5]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 14.06.19 05:36
Оценка: +3 :)
Здравствуйте, netch80, Вы писали:

C>>Но после перехода на С всё стало абсолютно кристально понятно сразу же.

N>Ну это ты зря. Как раз с синтаксисом указателей у Паскаля лучше.
В Паскале массивы — это нечто магическое (есть синтаксис динамических массивов, но тоже странный), а в С сразу всё становится понятно при работе с арифметикой. Такое же слышал и от других людей.
Sapienti sat!
Re[6]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 05:45
Оценка: +4
Здравствуйте, Cyberax, Вы писали:

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


C>>>Но после перехода на С всё стало абсолютно кристально понятно сразу же.

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

Я имею в виду то, что уже просто var x: ^integer; это лучше, чем int *x; и чем сложнее конструкция, тем легче её читать в таком виде.

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

Фокус в виде a[i] == i[a] == *(a+i) там не одобряют в чистом виде. Но в борландовской линии, по-моему, писать явно (a+i)^ было можно и нужно, если тебе в явном виде передали unsafe-указатель (хоть он так и не назывался).
Re[9]: Чем плох Паскаль?
От: T4r4sB Россия  
Дата: 14.06.19 08:16
Оценка: +4
Здравствуйте, kov_serg, Вы писали:

_>В паскале есть локальные функции. Чем не блоки?

Всем.
Re: Чем плох Паскаль?
От: Слава  
Дата: 13.06.19 18:17
Оценка: +2 -1
Здравствуйте, Cicero, Вы писали:

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


Моей основной претензией к Паскалю было отсутствие возможности самостоятельно сделать подобие Read/Write с переменным числом аргументов. Си это мог. Дальше, уже после знакомства с winapi CreateFile и сишным файловым API (даже в Borland C под DOS), меня очень раздосадовало отсутствие в файловых функциях паскаля всех возможностей создания-открытия файлов с учётом их присутствия, вроде CreateIfNotExists, CreateNew. То есть, операционка это может, даже DOS пресловутый, а в Паскаль это почему-то не завезли.

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

Вот уж язык — промышленней некуда, и плюсы пресловутые в некоторых случаях до сих пор с Адой сравнимы только условно. Там, где начинается всякая низкоуровневая высоконадёжная жесть, вместо плюсов берут обычный Си, ну а Ада-то будет побогаче си. И Ада точно так же может влезть в 64 байта на каком-нибудь особо мелком чипе. Для больших систем Ада тоже даёт больше возможностей, чем голый Си.
Re: Чем плох Паскаль?
От: _ABC_  
Дата: 13.06.19 19:25
Оценка: +3
Здравствуйте, Cicero, Вы писали:

C>Почему:

C>Говоря двумя словами: потому что в Паскале минимум неоднозначности синтаксиса.
C>ИМХО это научит контролировать код более строго.
А почему ты решил, что это важнейшая задача первоначального обучения в школе?

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

Вдруг среди важных задач совершенно внезапно стоит такая мелочь, как не отпугнуть от программирования среднестатистического современного ребенка... Не, ну вдруг?
Re[2]: Чем плох Паскаль?
От: Pzz Россия https://github.com/alexpevzner
Дата: 13.06.19 21:45
Оценка: +3
Здравствуйте, Cyberax, Вы писали:

C>В современном варианте было бы лучше что-то типа Питона с графической средой. Или как вариант: https://www.apple.com/swift/playgrounds/ — лучшее, что я вообще видел для детей.


Мне кажется, использование в качестве первого языка, языка с динамической типизацией, уродует головной мозг человека навсегда.
Re[3]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 13.06.19 22:58
Оценка: +3
Здравствуйте, kov_serg, Вы писали:

_>Почему некоторые люди считают что объявление переменных по месту это хорошо? Чем плохо заранее объявить что понадобиться, а не равномерно размызвать безполезное гавно по коду.

Какой смысл даёт объявление переменных в начале? Для любого современного компилятора это совершенно пофиг.

Для программиста не пофиг, так как нельзя с первого взгляда увидеть, где переменная получает значение. Ну и с иммутабельностью по умолчанию оно тоже никак не дружит.
Sapienti sat!
Re[5]: Чем плох Паскаль?
От: Пацак Россия  
Дата: 14.06.19 11:31
Оценка: +3
Здравствуйте, kov_serg, Вы писали:

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


Это примерно как предложить людям ходить исключительно строевым шагом, объясняя это тем, что "так обувь ровнее стаптывается и меньше шансов оступиться". Логика железная, но мало кто на это добровольно согласится.
Ку...
Re[2]: Чем плох Паскаль?
От: ksandro Россия  
Дата: 14.06.19 15:09
Оценка: +3
Здравствуйте, Джеффри, Вы писали:

Д>* Нет возможности легко разрабатывать UI, пусть даже и очень простой (Turbo Vision не предлагать). Иногда для ребенка может быть намного интересней сделать программу с окошком и кнопкой, похожую на реальное приложение, чем делать консольную утилиту с выводом в командную строку.

Д>* Наследие MS DOS — не знаю можно ли сейчас вообще легко запустить IDE на новых версиях Виндоус, объяснять почему длина имени файла не может быть больше 8 символов, возиться с кодировками и т.д.

Чувствую себя старым... Народ уже забыл что такое Delphi...
А ведь когда-то именно для паскаля появилась самая крутая IDE. Можно сказать первая IDE в современном понимании (VB не считается). И именно на паскале проще всего было писать оконные приложения под винду...
Re[5]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 14.06.19 18:16
Оценка: +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


Ну и где больше шума?
Sapienti sat!
Re: Чем плох Паскаль?
От: wildwind Россия  
Дата: 14.06.19 19:07
Оценка: +3
Здравствуйте, Cicero, Вы писали:

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

C>Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!

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

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

P.S. Аргумента "должен быть непременно C-подобный синтаксис" я принять не могу. Если ты изучаешь программирование глубоко и основательно, нужно изучать языки с разным синтаксисом; и научиться не путаться, переходя от одного к другому.
Отредактировано 15.06.2019 10:55 wildwind . Предыдущая версия .
Re[9]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 16.06.19 06:27
Оценка: +3
Здравствуйте, kov_serg, Вы писали:

_>Я же об этом и говорю должно быть с auto и выглядеть так:

_> CGBuilderTy &Builder = CGF.Builder;
_> auto Eq, And, Or, LPtr, RPtr, PtrEq, Zero, EqZero LAdj, RAdj, AdjEq, One, OrAdj, OrAdjAnd1, OrAdjAnd1EqZero, Result;
Это уже карго-культ какой-то. Объявления должны быть потому, что должны быть.
Sapienti sat!
Re[7]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 16.06.19 06:30
Оценка: +3
Здравствуйте, kov_serg, Вы писали:

M>>А в начале появляется шум. Даже не шум, а куча г.

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

M>>Кстати, про RAII слышал?

_>Если вам говорили что RAII вершина управления ресурсами то от вас многое утаили.
Лучше только Rust с borrow checker'ом.

_>Незнаю но многие упорно хотят видеть где переменная впервые использеутся. С этим спокойно спраиться IDE просто подсвечивая имя под курсором по всему тексту.

Ну и зачем тогда объявления в начале?

M>>Опять же. Определение переменной по месту экономит стек. Сейчас это не большая проблема на современных компиляторах, но раньше с этим было хуже

_>Вы серьёзно считаете что компилятор не способен определить когда и где создавать переменные.
Когда-то так и было. Первые компиляторы Паскаля были однопроходными, что и требовало объявлять переменные в начале. В результате поклонники секты Свидетелей Вирта эту багофичу вознесли в ранг Евангелия.
Sapienti sat!
Re[3]: Чем плох Паскаль?
От: AlexRK  
Дата: 23.06.19 07:24
Оценка: +3
Здравствуйте, __kot2, Вы писали:

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


"Идеальных". Жабаскрипт — это всестороннее уродство, которое для обучения просто вредно. Питон динамически типизирован и, как следствие, программы на нем подвержены ошибкам на этапе выполнения, что для обучения тоже скверно.
Re: Чем плох Паскаль?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 26.09.19 04:33
Оценка: +3
Здравствуйте, Cicero, Вы писали:

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

C>Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!

C>Давайте обсудим и выработаем обоснованные аргументы.


C>Во первых нужно конкретизировать:

C>для обучения где? в общеобразовательной школе? в ВУЗе? в ВУЗе которые готовят именно программистов?
C>как первый язык программирования? как второй?

C>Выскажу свое мнение:

C>Для обучения в школе как первый язык программирования с которым человек встречается Паскаль очень даже подходит.
C>Причем если не позволяет "железо" более современные версии вполне подойдет и Turbo Pascal 5.5.
C>На Turbo Pascal вполне можно обучать и элементы ООП.

C>Почему:

C>Говоря двумя словами: потому что в Паскале минимум неоднозначности синтаксиса.
C>ИМХО это научит контролировать код более строго.

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

Во-первых, начнём с конца: а что должно получаться у ученика в результате выполнения учебного задания?
Раз мы учим программированию, то, наверное, должна получаться программа.
Ну ок, в 1970 в качестве "программы" вполне подходили штуки, которые спрашивали с консоли значения a, b, и с, и выводили в консоль корни квадратного уравнения.
Но как бы сейчас 2019, среди детей уже нет IT-девственников. Детишки видели, как выглядят настоящие программы. Кому будет интересна вот эта вот консольная хрень? Да никому. Всё, что дети усвоят из такого курса программирования — что оно для фриков. И что их явно обманывают — потому что никаким эволюционным путём они не смогут превратить консольную программу в мобильный клиент альфабанка или хотя бы виндовый калькулятор.

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

Второе: средства языка. При рождении Паскаль был офигенно передовым языком. Вирт на нём преподавал структурное и процедурное программирование. Отлично. Но в современных языках, даже в тех из них, что насквозь императивные, появилось очень много всего — всякие замыкания, обобщённые типы, паттерн-матчинг, автовывод типов, вот это вот всё.
Даже турбопаскалевское ООП, которое было большим шагом вперёд относительно классического Паскаля, безнадёжно устарело.
Самый продвинутый и заинтересованный школьник сможет освоить на Паскале едва пятую часть языковых конструкций, которые встретятся ему в реальном промышленном программировании.

Моя точка зрения такова: для понимания принципов программирования, своевременных в 6-9 лет, подходит какой-нибудь наглядный язык программирования вроде Лого.
Он не претендует на то, чтобы создавать настоящие программы, зато поможет детишкам освоится с самыми основами — что компьютер, в общем-то, делает то, что ему скажут. И всё программирование сводится к тому, как правильно объяснить компьютеру, что от него нужно.

Для освоения самого программирования нужен язык + среда, которые
а) содержат современные языковые конструкции
б) позволяют писать настоящие полноценные программы, пусть даже и простые

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

Ещё недавно хорошо бы подошёл Delphi — как раз потому, что на нём состряпать свой первый hello world занимает секунды, а вся неаппетитная начинка спрятана под капот. При этом hello world будет не серым текстом на чёрном фоне, а вполне себе настоящим приложением, достойным запуска на windows desktop. И дальше можно изучать вширь — осваивая новые компоненты и способы их совместного применения, и вглубь — понимая, как эти компоненты устроены внутри.

Увы, сейчас даже Delphi староват. Что у нас на рынке? бэкенд, веб-фронтенд, мобильные приложения. Для них надо что-то получше дельфей.
По-хорошему, нужна среда, которая позволяет сделать шлёп-шлёп приложение для iOs/Android — чтобы маме на телефон поставить, и оно по-настоящему заработало. Чтобы детишко понимало: ну ок, я вижу не всю картинку — чтобы это приложение продавалось, надо ещё в 10-100 раз больше работы провести, но я эту работу провести могу! Знаю что, знаю как, знаю, где почитать о том, чего пока не знаю.

А не так, что вот вам сложение, вот умножение, вот деление с остатком, всё, теперь вы знаете всю математику — А ТЕПЕРЬ РЕАЛИЗУЙТЕ-КА МНЕ ШИФРОВАНИЕ НА ЭЛЛИПТИЧЕСКИХ КРИВЫХ!
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re: Чем плох Паскаль?
От: Александр Кузнецов Россия  
Дата: 14.06.19 08:47
Оценка: 6 (1) +1
Здравствуйте, Cicero, Вы писали:

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

C>Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!

Паскать — это язык, который специально затачивался под обучение. С этой точки зрения он очень даже хорош. А вот дальше, как говорится, есть нюанс...

Паскаль — это мёртвый язык. Уже лет 10 как, даже с учётом попыток особо упёртых некромантов реанимировать Дельфи (которая тоже мертва не смотря на все её несомненные плюсы). Как следствие, любому школьнику/студенту, которому придётся учить этот язык, придётся потом переучиваться на что-то другое. Может показаться — фигня. Но это фигня для опытного разработчика, который повидал с 10-к вариантов "циклов" и т.д. в разных ипостасях. Для школьника/студента это тупо увеличение нагрузки по курсу раза в полтора. На мой скромный взгляд лучше ему голову чем-нибудь более полезным загрузить. Теми же алгоритмами, например, параллельными вычислениями, или промышленной разработкой.

Отсюда, кстати, вытекают и другие нюансики.

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

C>Причем если не позволяет "железо" более современные версии вполне подойдет и Turbo Pascal 5.5.
Основная проблема современного железа как раз обратная. В ВУЗе/школе ещё можно найти свалку "мечта некрофила" с компами, на которых кроме MS-DOS и Win 95 ничего не запускается, но в магазинах такие компы не продаются, уж извините. А студенты/школьники себе берут именно их. И тут выясняюся очень интересные вещи.
Например, старый DOSовский Turbo Pascal запустить, конечно, можно, с определёнными танцами, но вот попытки стартовать графический режим будут обречены на провал. А это автоматически минус довольно плотный пласт задачек и возможностей.

C>На Turbo Pascal вполне можно обучать и элементы ООП.

Не надо так. Технически — можно. Практически — там немного порезанная версия ООП. Но главное, даже, не в этом. ООП объяснять на типичных "досовских" задачках не вариант. Можно, конечно, но все примеры будут настолько искусственными, что пролетят мимо студенческого мозга с субсветовой скоростью. Что работает? Большие промышленные задачи на несколько человек, игры посложнее и т.д. Но это не пишут на Паскале.
Я пробовал писать в своё время на Паскале оконную графическую библиотеку, знаю о чём говорю. Можно? Да. Но у студентов будет куча вопросов к адекватности преподавателя. А уж с учётом описанного выше нюанса про графику, всё становится вообще печальным.

C>Почему:

C>Говоря двумя словами: потому что в Паскале минимум неоднозначности синтаксиса.
Я вам открою страшную тайну: за исключением JavaScript, все "современные" языки программирования (по крайней мере из числа более-менее использующихся на практике) практически не имеют неоднозначностей в синтаксисе. По крайней мере на том уровне, на котором учат в школё/ВУЗе. Даже классический анекдот про то, что можно, и чего нельзя написать на C и Pascal — это не более чем анекдот. Ибо на Паскале можно писать конструкции не сильно понятнее. Хотя и затратив на это чуть больше усилий, да. Это вопрос в основном культуры написания кода, которую просто надо прививать.
И да, соглашусь, на том же С формально это делать немного сложнее, чем на Паскале. Зато гораздо нагляднее )

C>ИМХО это научит контролировать код более строго.

Вот тут позволю себе не согласться, причём также ИМХО Ничто так не учит контроллировать, например, выход за границу массива, как пара раз "мордой в грязь". Паскаль в этом плане гораздо менее нагляден ))).

Если на полном серьёзе, то из опыта подготовки уже даже и не сосчитаю скольки студентов (но боюсь, что уже за 1000 перевалило) от первого курса и до работы в производстве, могу сказать, что первый язык должен быть максимально близок к тому, с чем им придётся работать на протяжении обучения и дальше. Т.е. это:
1. С-подобный синтаксис. Да, я в курсе про то, что регулярно изобретают кучу велосипедов (не как в С (тм)). Примерно 1 на 100000 из них даже реально приживаются в производстве для решения специфического класса задач. Но тем не менее подавляющее большинство разработчиков работают именно с С-подобными языковыми конструкциями. Это как с базами. Стандарт — SQL, хотя есть варианты.
2. Поддержка основных парадигм программирования (функциональное и ООП).
3. Возможность залезть в "потроха" до уровня указателей и работы с памятью.
4. Поддержка графических режимов на относительно простом уровне, без 100-500 танцев с бубном.
5. Крайне желательна возможность со временем отказаться от написания велосипедов в пользу использования библиотечных функций.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Re: Чем плох Паскаль?
От: velkin Россия  
Дата: 13.06.19 19:38
Оценка: +2
Здравствуйте, Cicero, Вы писали:

C>Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!


Недостатки языка Pascal:
1. касательно парадигм программирования — только процедурное программирование
2. касательно библиотек алгоритмов — практически отсутствуют

ВУЗы правда применяют и гораздо более худшие варианты обучения, например, использование C++ до стандарта ISO/IEC 14882:1998 года. Вот где настоящее вредительство и издевательство над учащимися.

Но самый большой недостаток на мой взгляд это учебная программа по Pascal. Обычно она заканчивается изучением синтаксиса языка на примерах сильно отличных от реальности. Можно ли сделать что-либо полезное на Pascal? Да, можно, но этому учить не будут. Напротив, после подобного обучения может создастся ощущение бесполезности данной реализации языка.

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

Если же говорить о каких-либо особых преимуществах Pascal перед другими языками программирования, то их нет.
Re[2]: Чем плох Паскаль?
От: pagid Россия  
Дата: 14.06.19 03:46
Оценка: +1 -1
Здравствуйте, itmanager85, Вы писали:

I>зачем обучать мёртвому языку ?

Для понимания принципов.

I>намного более актуальны c/c++ | Java | C# | PHP | MySql — после них хоть к станку

В обсуждаемом не должно быть цели "после к станку". Даже в ВУЗе при начальном обучении программированию не должно быть такой цели.
I>(особенно если JS/JQuery добавить)
это мусор к программированию как учебной дисциплине не имеющий никакого отношения.
Re[3]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 04:50
Оценка: +2
Здравствуйте, pagid, Вы писали:

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


I>>зачем обучать мёртвому языку ?

P>Для понимания принципов.

Из этого не следует необходимость обучения мёртвому языку.
Из живых на эту роль отлично подходит, например, Go (ближайший по духу), Java, C#, Python. Для системного уровня — C.

I>>намного более актуальны c/c++ | Java | C# | PHP | MySql — после них хоть к станку

P>В обсуждаемом не должно быть цели "после к станку". Даже в ВУЗе при начальном обучении программированию не должно быть такой цели.

Во-первых, должна быть. Учат чему-то полезному, и конкретный язык здесь, хоть и не первоочередная составляющая, но важная. А если ещё при обучении человек сразу включается в реальную работу и видит полезный выхлоп от своей работы — то это ещё больше работает на качество обучения.
Во-вторых, тем более не должно быть цели учить тому, после чего надо заново переучиваться.
Отредактировано 14.06.2019 5:09 netch80 . Предыдущая версия .
Re[4]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 04:53
Оценка: +1 -1
Здравствуйте, Cyberax, Вы писали:

C>>> работа с динамическими структурами вообще совсем никакая. Указатели в Паскале придумали какие-то извращенцы.

С>>Что там не так с указалями?
C>Совершенно дикий синтаксис, который ни на что не похож. Я начинал учить программирование с Паскали, и так и ниасилил их.

C>Но после перехода на С всё стало абсолютно кристально понятно сразу же.


Ну это ты зря. Как раз с синтаксисом указателей у Паскаля лучше.
Re[5]: Чем плох Паскаль?
От: T4r4sB Россия  
Дата: 14.06.19 06:31
Оценка: +2
Здравствуйте, kov_serg, Вы писали:

C>>Ну и с иммутабельностью по умолчанию оно тоже никак не дружит.

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

Потому что значение переменной может зависеть от результата выполнения сложного блока, то есть объявить её со значением до этого блока нельзя.
А ещё переменная может быть нужна лишь в одной из веток алгоритма. А в другой ветке нужна другая переменная того же типа. И в итоге получаем либо распухший список переменных в начале функции, либо вредную привычку вместо index для одной ветки и tmp для другой заводить одну specail_int и использовать её везде. Сейчас вы скажете, надо функции мельче делать?
Re[6]: Чем плох Паскаль?
От: night beast СССР  
Дата: 14.06.19 11:34
Оценка: +2
Здравствуйте, AlexRK, Вы писали:

N>>в if, else, while нужно строить блок вокруг нескольких предложений, а в repeat-until — нет


ARK>В Ц/Ц++ то же самое — в do надо обязательно ставить {}, а в других местах — нет.


шито?
Re[7]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 14.06.19 17:10
Оценка: +2
Здравствуйте, Sharowarsheg, Вы писали:

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

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

Тут стоит задуматься, что торайдиционные программы, которые мучают детей массивами, стоит как бы немного пересмотреть.
Sapienti sat!
Re[2]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 14.06.19 22:09
Оценка: +2
Здравствуйте, wildwind, Вы писали:

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

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

W>В зарубежных вузах на соответствующих курсах уже давно используют Modula 2; а сейчас наверное уже что-то и более современное.

В "зарубежных курсах" Паскаль давно похоронили. В качестве первого языка чаще всего берут Питон, затем С/С++/Java.
Sapienti sat!
Re[7]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 15.06.19 04:15
Оценка: +2
Здравствуйте, 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>Какие в школе расширенные случаи? Даже сортировка... написали один раз сортировку пузырьком, и достаточно. Больше она нигде в школьной программе не нужна, по крайней мере в той школьной программе, которой меня учили. А школьная программа, по которой меня учили, была слишком сложная и так, оттуда бы ещё половину выкинуть.


Так минимум на треть кривизна программы как раз из-за того, что рассчитывается под отсутствие стандартной библиотеки.
Re[6]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 15.06.19 04:30
Оценка: +2
Здравствуйте, Александр Кузнецов, Вы писали:

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. Статьи «как всё плохо» на условном хабре.

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


Я видел больше вариантов. Кто-то привык к очень странному стилю, кто-то подтачивается под любимый фреймворк (подходы которого именно тут неуместны)...
Re[9]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 03:56
Оценка: +2
Здравствуйте, kov_serg, Вы писали:

_>>>И вынесенные объявления.

C>>Уродство. Чистейшее уродство из-за повреждения моска Паскалем.
_>Видимо вы уже не способны мыслить. И не видите очевидного.

"Не способны мыслить" и не видят очевидного тут скорее защитники паскалевского стиля:

C>>Я уж не говорю, что все определения нынче легко можно заменить на "auto". В данном случае явный тип переменной по месту служит дополнительной документацией (чтобы не нужно было IDE напрягать), тогда как в варианте "мессиво в начале функции" он полностью бесполезен.


_>Я же об этом и говорю должно быть с auto и выглядеть так:


Пусть по одной ветке тип получает значение complex<float>, по другой double, по третьей — string.
Какой тип будем дедуцировать?

А если тип должен определять, какой из перегруженных вариантов функции должен вызваться?
Re[8]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 19.06.19 08:14
Оценка: +2
Здравствуйте, pagid, Вы писали:

C>>Организация памяти — это скорее изучение математики с теории множеств и арифметики Пеано.

P>Это если углубляться, где школьникам делать действительно нечего — виртуальную память, страничную и, прости господи, сегментную организацию памяти. Но если уж решили учить программированию, то сказать что ОП это последовательность пронумерованных байт придется.
Ну да, рассказать можно и даже нужно, в качестве заметки на полурока. Заниматься разборами представления чисел в памяти — в базовом курсе не нужно.

C>>Да, организация памяти — это очень базовая вещь, но её тупо можно пропустить.

P>Так можно все, что угодно пропустить, но мы возвращаемся к исходному, для чего этот предмет и что там нужно изучать
Есть мнение, что так и надо делать.

Я знаю людей (не программистов), которые ничерта не понимают в основах программирования, но пишут вполне неплохие скрипты на Питоне или Matlab. Так что я не вижу никаких проблем в том, что будет больше упор на практические стороны.
Sapienti sat!
Re[4]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 19.06.19 11:06
Оценка: +2
Здравствуйте, pagid, Вы писали:

C>>А зачем?

P>А зачем в школе предмет — информатика? Может и не нужен но если нужен, то как минимум про байты с битами придется рассказать, про организацию памяти, в простейшем виде, с линейной адресацией наверно тоже. Можно конечно предполагать, что библиотекарше и секретарше достаточно будет знать почти человеческий SQL Excel Питон. Но он точно школьку нужен больше, чем байт с битом?

В идеале инфоратика должна научить человека как объяснить машине сделать то что ему нужно. И желательно как можно проще.
Например заставить компьютер считать количество витков на трансформаторе, перевести список контактов из exel в iphone, распечатать шаблон детали или
решить диф уравнения для определения распределения температур и т.п.

И еще показать к чему приводит использование компьютеров, когда не понимаешь что хочешь.
и показать весь этот бл%^&кий цирк каменный век по подготовке к работе с нашими гос услугами личными, кабинетами, цифровыми подписями и криптопровайдерами
Re[2]: Чем плох Паскаль?
От: elmal  
Дата: 20.06.19 08:31
Оценка: +2
Здравствуйте, LaptevVV, Вы писали:

LVV>Вот и все несовременность.

Проблема в том, что в советско-российских реалиях если брать школу, то из 30 учеников, изучающих информатику на паскале, хоть что то понимают от силы 2 человека. Если брать институты и кафедры вроде прикладной математики, то понимают то, чему их там учат на паскале — из 30 человек возможно человек 5. При этом со всякими матлабами дела обстоят немного получше, правда при условии, что студент к этому времени не забьет на учебу и не начнет работать на фултайме на какой низкоквалифицированной, но относительно оплачиваемой работе.

Соответственно основная проблема паскаля — для новичков он в современном понимании слишком сложен. Есть языки проще. На которых можно быстро написать что то простое и полезное. Например можно быстро написать базовую проверку орфографии во входном файле. На паскале это не совсем тривиальная задача, на других языках это писать 15 минут. Соответственно вопрос — нахрена отпугивать новичков излишней сложностью и низкоуровневостью на ровном месте? Что, современные детишки или студенты стали на порядок более умными, чем были при СССР чтоль, соответственно на джавах питонах для них будет слишком просто, нужно искусственно усложнить?
Re[12]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.06.19 20:44
Оценка: +2
Здравствуйте, AlexRK, Вы писали:

ARK>Опять отсылки к малоформализуемым вещам — "сохранность данных", "корректность операций".


Это как раз в разы формализуемее.

Сохранность данных: у типа A есть множество значений V(A), у B есть множество значений V(B).
Если ∃a: a∈V(A) ∧ a∉V(B), то конверсия A -> B может давать потерю данных, и должна быть запрещена в неявном виде.
Банальный пример: int32 и int16. +32768 входит в множество значений int32, но не int16. Преобразование возможно, но явной операцией, для которой желательно задание, что делать в случае реального выхода за границы (варианты: проигнорировать с оставлением младших разрядов, выбрать ближайшее представимое значение, сгенерировать исключение, выставить заданную флаговую переменную в 1...)
Более хитрый пример: 16777216 и 16777218 входят в множество значений int32 и float32, но 16777217 входит в int32, но не во float32 (и при преобразовании будет округлено до одного из двух соседей). Преобразование возможно, но явной операцией (для которой желательно иметь возможность задать режим округления).

Сохранение семантики: если A(), B() это конверсии к соотв. типам, и A(B(x) op B(y)) != x op y для некоторой op и некоторых a, b ∈ A, то автоконверсия A->B недопустима. (Аналогичное может быть для операций любой арности и разных типов, но облом всё расписывать.)
Простейший пример: если "+" складывает числа, но конкатенирует строки, то нельзя допускать автоконверсии числа в строку, если может получиться, что 3+5 == 8, но '3'+5 == 3+'5' == '35'.
(В Perl этой ловушки избежали: там "." для конкатенации. В JavaScript — наступили с разгону.)

Для встроенных типов всё это должен обеспечивать язык. Для определяемых программистом — задача на этом программисте, но язык должен не мешать этому.

ARK>У меня четкое формальное определение, а у вас что-то аморфное, что и на определение, ИМХО, не особо тянет. Интересно, для чего ваш вариант полезнее, для победы в форумных спорах?


Моё — для практики применения в языках.
Это ваше — для форумных споров: чОткая формальность с исчезающе малой практической применимостью.

N>>А ваше определение противоречит вашему же подходу с примерами: два типа array[1..9] of integer, очевидно, одной структуры — значит, неявное преобразование возможно и желательно.


ARK>1) Мое определение ничему не противоречит.

ARK>2) Пример с массивами не мой.

OK. Но ваш такой же
Автор: AlexRK
Дата: 20.06.19
.

ARK>3) Да, неявное преобразование в данном случае возможно, и это не противоречит сильной типизации. Не стоит путать теплое с жидким, то есть сильную типизацию с номинативной.


Я и не путаю. Это вы меня с кем-то путаете.

N>>Вы уже второй раз в этом треде читаете полностью противоположное тому, что я писал, и приводите пример на это противоположное прочтение.

ARK>А где первый раз был?

В 7475483.

N>>Вы уже запланировали отпуск? По-моему, пора.

ARK>Лучше вам на себя оборотиться: http://rsdn.org/forum/education/7474126?tree=tree
Автор: netch80
Дата: 19.06.19

ARK>

А, я криво прочитал.

ARK>А то, понимаешь, "читаете полностью противоположное тому, что я писал, и приводите пример на это противоположное прочтение" (с)

Там было рядом с нужным, а вы полностью противоположное находите.
Re[3]: Чем плох Паскаль?
От: Privalov  
Дата: 23.06.19 07:24
Оценка: +2
Здравствуйте, MamutArGud, Вы писали:

MAG>Это тот самый кумир, который алг нач цел вещ все кон? За что?


  qsort
MAG>
MAG>алг qSort(аргрез целтаб A[1:5], арг цел iStart, iEnd)
MAG>нач
MAG>  цел L, R, c, X
MAG>  если iStart >= iEnd то выход все
MAG>  L:= iStart; R:= iEnd;
MAG>  X:= A[div(L+R,2)]
  
MAG>  нц пока L <= R
MAG>    нц пока A[L] < X; L:= L+1 кц
MAG>    нц пока A[R] > X; R:= R-1 кц

MAG>    если L <= R то
MAG>      c:= A[L]; A[L]:= A[R]; A[R]:= c
MAG>      L:= L+1; R:= R-1
MAG>    все
MAG>  кц

MAG>  qSort(A, iStart, R)
MAG>  qSort(A, L, iEnd)
MAG>кон
MAG>


Я не очень понял, служебные слова по-русски можно, а идентификаторы — нет? Тогда это издевательство не только над детьми. Вот если можно все на одном языке, тогда можно о чем-то рассуждать. Но клавиатуру перенастроить придется. Чтобы не переключаться лишний раз.

P.S. Пока писал, заметил div. Надо полагать, это целочисленное деление. Тогда все не слишком радужно.

P.P.S. Интересно, Валерий Викторович свою обучающую среду допилил до нормальной работы с языками?
Re[3]: Чем плох Паскаль?
От: AlexRK  
Дата: 26.09.19 11:08
Оценка: +2
Здравствуйте, MasterZiv, Вы писали:

MZ>P.S. Паскаль -- говно. Всегда был говном и останется говном. Вирт дебил.


Это мнение либо круглого дурака, либо тролля. А Вирт за паскаль получил премию Тьюринга.
Re[5]: Чем плох Паскаль?
От: Privalov  
Дата: 30.06.19 13:26
Оценка: 6 (1)
Здравствуйте, MamutArGud, Вы писали:

MAG>Прям отличная система для обучения.


Вспомнил. Много дет назад я сталкивался с языком АП на ЭВМ Наири-3. В нем тоже все по-русски было. ИНо чтобы понять программу, нужно было знать кое-какие нюансы.
Например, оператор ВСТАВИМ — это оператор присваивания. Без него не работало а = а + 1.
Непонятно без объяснения, чем отличается КОНЧАЕМ от ОСТАНОВ.
Было еще всякое, но за давностью лет забыл все напрочь.
ЕМНИП, в АП можно было писать русские идентификаторы.
Но из-за всех этих нюансов с искажениями смысла слов на родном языке происходил взрыв мозга. И когда на горизонте появился Фортран 4, мне стало легче. Я просто запомнил английские слова, не особо вникая в исходный смысл их.
Наверное, системы программирования на русском языке нужны. Но как их правильно проектировать, я не знаю. Ясно только, что нужно привлекаьб хороших лингвистов.
P.S. Что-то я не могу найти примеров на АП. Он, видимо, давно и прочно забыт. Вот тут есть очень краткий обзор. И там же — пример программы или что-то вроде того.
http://1.bp.blogspot.com/-N6_Pz6PUhik/VliKzOQ9ywI/AAAAAAAATsk/G6imSSLAWx4/s1600/%25D0%25BD%25D0%25B0%25D0%25B8%25D1%2580%25D0%25B8%2B%25D0%25AF%25D0%2590%25D0%259F.JPG
Re[6]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 19:30
Оценка: 4 (1)
Здравствуйте, AlexRK, Вы писали:

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


MAG>>В каком месте в C, C++, Java и т.п. есть разделение на процедуры и функции?


ARK>Ну как же. Так называемый "тип" void — это вот оно и есть.


Не так. В исходном Pascal у функции, кроме возвращаемого значения, ещё одно свойство: отсутствие побочных эффектов — нельзя присваивать ничего за пределами, нет var-параметров. Сейчас это принято называть, что функция чистая (pure).
В Turbo версии и вслед за ней во всех реальных это, насколько помню, похерили. С этого момента (и особенно с появлением var-параметров у функций) и получилось, что procedure f === void f(), а function f: type === type f, и больше принципиальной разницы нет.
Но вначале оно было жёстко принципиальное.

ARK>>>- они все тоже туда же. Иди попробуй объясни, зачем в сикраше Action и Func ... да хоть кому бы то ни было. Выкинуть и забыть этот весь шлак как страшный сон!

MAG>>Это скорее из-за ущербности системы типов и дизайна.
ARK>Безусловно. Но по факту это и есть деление на процедуры и функции.

В C/C++, по описанному, его никогда не было.
Сейчас вроде бы где-то можно объявить, что функция является pure, как полезный хинт анализатору (где-то отклонение — он пожалуется).

ARK>Вот такого — нету, а это и есть самое главное. "void" — это не тип, а заглушка. Это и есть "procedure", только записывается короче.


1. См. выше.
2. Если уже говорить про подобные возможности, то надо вспоминать и возврат не одного значения из функции, а многих. В C++, считаем, есть (хоть и криво — ни один ABI это ещё не позволяет напрямую; std::pair, std::tuple приводят к возврату структуры через скрытый параметр — указатель), и можно использовать (да хоть монады на нём строить). В Паскале нет и не ожидается.
Re[3]: Чем плох Паскаль?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 26.09.19 10:55
Оценка: 3 (1)
Здравствуйте, Vlad_SP, Вы писали:

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


Эмм... Если честно, то полного готового ответа на этот вопрос у меня нет.

V_S>Ведь из "среднего" такого школьного класса профессиональными программистами станут дай то Б.Г. 1-2% учеников. Остальные станут — доярками, писателями, водителями, поварами, врачами... ну и так далее, список профессий можно расширять до бесконечности. Зачем им "реальное промышленное программирование"??? Кой черт водителю сдался этот самый Паскаль или там не дай Б.Г. JavaScript ?

Отлично. А на кой чёрт программисту баскетбол, или, не побоюсь этого слова, Русский Язык?
Ладно, упростим — повару география зачем?
Физику — история?
Писателю — биология?
V_S>Вот возьмем к примеру девочку, мечтающую стать балериной. На уроках алгебры условная Марь Ванна талдычит что-то про свои синусы и катеты. Да девочка забудет все эти катеты как страшный сон, на следующее же утро после сдачи ЕГЭ! И ровно то же самое произойдет, когда на уроках "программирования" условный Сан Сеич будет ей талдычить о каких-то переменных, циклах и не дай Б.Г. каких-то "замыканиях".
V_S>Факультативно (факультативы там в школе, кружки программирования и т.д.) или "с углубленным изучением" — эт да. А в обычной-то средней школе тот же Паскаль — зачем??
Смотрите, как это работает:
1. Сначала мы окорачиваем среднюю школу. Ну, то есть оставляем в ней только то, что прямо таки должны знать все-все-все: доярки, писатели, балерины, повара, врачи, шофёры... ну и так далее.
2. Всё остальное в ней — факультатив. Пусть даже с гос.финансированием.
3. Дети, естественно, перестают на эти факультативы ходить — точнее, ходят только на те, которые сочли важными родители вроде вас, считающих какие-то предметы лишними.
4. В итоге через 11 лет таких реформ мы имеем людей, которые не просто не знают каких-то дисциплин, а вообще о них не осведомлены. Не знают не просто астрономию, а о том, что астрономия вообще есть.
5. Дальше начинается кумулятивный эффект — потому, что сейчас вы наблюдаете людей, которым хотя бы пробовали преподавать синусы и косинусы. У кого-то были нормальные учителя, и дети что-то в голове оставили. У кого-то было поплоше, поэтому реальные выпускники знают курс средней школы не на 100%, а на, скажем, 25%. Так вот после того, как мы снизим планку, выпускники тоже будут знать 25%. Только не от нынешей программы, а от той — упрощённой.


Ещё Замечу, что девочка, которая в 4 классе мечтала стать балериной, запросто может к 8му растолстеть, и полностью пересмотреть своё отношение к жизни. Средняя школа (в нормальном её варианте) даёт ей возможность передумать, полюбить что-то другое, и заняться именно им.
В каком классе девочка (или её родители) должны делать выбор? Ну, вот мне, например, повезло — я с 8го класса знал, что хочу в IT.
А младшая сестра до 11 класса думала, что станет филологом. А стала таможенником. Оппа!

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

Дупа — в том, что такие люди неконкурентоспособны. Такой подход резко увеличивает социальное неравенство, потому что преимущество получают те дети, у родителей которых есть деньги и мотивация учить детей за пределами началки. Физматшкол в стране всего 4. Вы предлагаете всех остальных ничему не учить, 200 человек в год — достаточная численность основы нашей элиты.


НЕТ.
Ребёнок должен иметь возможность стать кем угодно.
Начальная школа даёт ему возможность в обществе существовать — потому что без базовых навыков чтения, письма, и счёта он тупо не сможет квартплату оплатить и в магазине консервы отличить друг от друга.
Средняя школа даёт возможность выбрать, кем становиться.
Высшая — стать этим кем-то.
Исходя из этого, программирование должно помочь детям понять, что такое программирование вообще, и как оно устроено. Даже чтобы руководить программистами, начислять им зарплату, или заказывать у них работу, желательно представлять себе, как всё это работает.
Вот примерно как я себе всё это вижу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re: Чем плох Паскаль?
От: vsb  
Дата: 13.06.19 17:40
Оценка: -1
Паскаль плох тем, что не применяется на практике. Лет 15 назад ещё как-то применялся в дельфи, сейчас совсем сдох. А в остальном хороший язык, да, особенно если ограничиваться оригинальным подмножеством, а не турбо-паскалем. Если нужно учить человека программированию всерьёз, например в университете, паскаль это хороший вариант.
Re[2]: Чем плох Паскаль?
От: Слава  
Дата: 13.06.19 19:32
Оценка: :)
Здравствуйте, netch80, Вы писали:

N>Вирт, кстати, часть этих огрехов Pascal исправил, создав Modula.


Вы забыли ещё про синтаксический оверхед написать.
Re[2]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 13.06.19 22:09
Оценка: -1
Здравствуйте, elmal, Вы писали:

E>5) В современном мире паскаль прививает крайне хреновый стиль программирования. Только недавно сделали возможность объявлять переменные по месту использования;


Ради срача

Почему некоторые люди считают что объявление переменных по месту это хорошо? Чем плохо заранее объявить что понадобиться, а не равномерно размызвать безполезное гавно по коду.
Отредактировано 13.06.2019 22:14 kov_serg . Предыдущая версия .
Re[3]: Чем плох Паскаль?
От: marcopolo Россия  
Дата: 13.06.19 22:10
Оценка: :)
Здравствуйте, Pzz, Вы писали:

Pzz>Насколько я могу судить, причина тому — странная причудь Вирта оформлять вызов фукнции без аргументов в виде имени функции без скобок. Отсюда невозможность понять, если такая функция возвращает указатель на функцию, то что имеется ввиду, она сама или возвращаемое ей значение. Ну и как сомнительное решение этпй проблемы — отсутствие возможности вернуть указатель на функцию вообще.


Ну все, что вы тут понаписали, не стоит и выдеенного яйца по сравнению с теми тормозными сишными приложениями, которые сейчас пишут с использованием .dot или с десктопными ява-приложениями.
http://images.vfl.ru/ii/1458025806/ffafd500/11874919.png
Re[4]: Чем плох Паскаль?
От: pagid Россия  
Дата: 14.06.19 08:06
Оценка: +1
Здравствуйте, netch80, Вы писали:

N>Из этого не следует необходимость обучения мёртвому языку.

N>Из живых на эту роль отлично подходит, например, Go (ближайший по духу), Java, C#, Python.
Тоже можно. Но в C# и Java больше условностей совершенно излишних — не забыть импортировать пакеты, написать хотя бы один класс, ни к чему это школьникам.


N>Для системного уровня — C.

Зачем системный уровень школьникам


N>Во-первых, должна быть. Учат чему-то полезному, и конкретный язык здесь, хоть и не первоочередная составляющая, но важная. А если ещё при обучении человек сразу включается в реальную работу и видит полезный выхлоп от своей работы — то это ещё больше работает на качество обучения.

Математике и литературе в школе тоже учат чтобы можно было сразу включиться в реальную работу?

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

Что там переучиваться если разговор про первоначальное обучение там что переучиваться на другой язык, что доучиваться на том же до профессионального уровня трудозатраты примерно те же. А при этом представление о том, что языки бывают разные вредным не будет.
Re[6]: Чем плох Паскаль?
От: AlexRK  
Дата: 14.06.19 08:15
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>>>Но после перехода на С всё стало абсолютно кристально понятно сразу же.

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

А в Го массивы, хеши, каналы — это не магическое, не? Синтаксис не странный?
Re[3]: Чем плох Паскаль?
От: koenig  
Дата: 14.06.19 09:13
Оценка: +1
I>>зачем обучать мёртвому языку ?

A>В инязе обучение английскому начинают с латыни. Ну это так, в качестве примера.



нормальные герои всегда идут в обход
Re: Чем плох Паскаль?
От: koenig  
Дата: 14.06.19 09:15
Оценка: +1
да нормальный он, сгодится
Re[3]: Чем плох Паскаль?
От: Александр Кузнецов Россия  
Дата: 14.06.19 09:22
Оценка: +1
Здравствуйте, alpha21264, Вы писали:

I>>зачем обучать мёртвому языку ?


A>В инязе обучение английскому начинают с латыни. Ну это так, в качестве примера.


Ну, английский, всё-таки, от латыни произошёл, значительную часть слов и конструкций вполне себе успешно из неё заимствовал, и в некоторых моментах для понимания, "почему так" латынь там вполне себе может помочь.
А вот начинать учить английский с, например, старонорвежского, я бы всё-таки не советовал.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Re[4]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 11:17
Оценка: +1
Здравствуйте, Александр Кузнецов, Вы писали:
ARK>>Я вам открою страшную тайну: все "современные" языки программирования (по крайней мере из числа более-менее использующихся на практике) имеют немало неоднозначностей в синтаксисе. А в Ц++ этих неоднозначностей столько, что даже парсинг кода не может быть выполнен без семантического анализа.

АК>Если честно, то на вскидку не могу припомнить ни одной. Либо мозг уже давно привык эти неоднозначности вполне себе однозначно разбирать, либо в командах, в которых мне приходилось работать, всегда слишком строгое соблюдение coding style было.


Есть два разных понимания "неоднозначности синтаксиса": одно — для того, кто пишет код, другое — для парсера. Частично они пересекаются, конечно.

Для того, кто пишет, важны, например, такие вещи, что в if, else, while нужно строить блок вокруг нескольких предложений, а в repeat-until — нет; что в конце main надо ставить точку после end, а у остальных — точку с запятой; что var идёт перед основным телом; что and и or почему-то приоритетнее сравнений; ну и так далее.

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

Второе — это таки что нужно делать парсеру, чтобы понять, как этот код интерпретировать. Тут Паскаль по лёгкости и однозначности разбора если не на первом месте, то близко к тому. Конечно, LISP с его LL(0)/LR(0) он не победит. Но ряд вещей в Паскале намеренно сделан в сторону облегчения разбора до уровня, когда нет никаких вариантов для отката и надо заглядывать не более чем на одну лексему: например, поэтому перед else не полагается ';', а метки для goto сделаны числами (иначе, увидев aaa, было бы ещё неясно, это aaa := 3 или aaa: bbb := 4).

А вот C++ представляет собой один из наиболее кошмарных в этом смысле примеров. Даже имея простое x *y; , вы не знаете, не проверив типы всех элементов, это объявление y как указатель на x или умножение x на y, которое имеет важные тут побочные эффекты. При том, что что такое x, может быть объявлено ниже по телу определения класса, это значит, что выбор между вариантами надо отложить.
Другой классический пример вида A B(C); точно так же откладывается до выяснения, что такое C. Подробнее, например, тут. Или вот такой пример. Или проблема с ">>", про которое заранее неизвестно, это закрытие двух шаблонов за раз или оператор сдвига (и при этом вполне может быть что-то вроде aaa<bbb<(ccc>>ddd)>>, потому что параметрами шаблона могут быть константные числа).

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

Так что — определитесь, о чём вы. Если о неоднозначностях для парсинга, то вам пора таки обновить своё понимание в этой области. Если для пишущего...
вот честно говоря, написать сложную конструкцию серьёзнее, чем a (*b)()[3]; без бутылки будет трудновато. Так что C/C++ и в этом смысле ой.
Отредактировано 14.06.2019 11:19 netch80 . Предыдущая версия .
Re[6]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 11:39
Оценка: +1
Здравствуйте, AlexRK, Вы писали:

N>>в if, else, while нужно строить блок вокруг нескольких предложений, а в repeat-until — нет

ARK>В Ц/Ц++ то же самое — в do надо обязательно ставить {}, а в других местах — нет.

Что в do обязательно?

do
  x();
while(y);


компилируется без проблем.

N>>в конце main надо ставить точку после end, а у остальных — точку с запятой

ARK>Дааа... в других-то языках все иначе, да?

Все описанные тобой проблемы это запреты на разные хаки, а простое прямолинейное решение как раз не мешается с этим. А в Паскале надо даже написав hello world помнить, что тут именно '.', а не ';'

N>>что and и or почему-то приоритетнее сравнений

ARK>А почему должно быть наоборот?

Потому что приоритеты операций придуманы не от балды, а чтобы упростить наиболее типовое применение.
Если бы сложение было приоритетнее умножения, и надо было бы a+b*c писать a+(b*c), чтобы его не поняли как (a+b)*c, то аналогичные жалобы были бы и тут.
Запись типа if a=0 and b>0, понимаемая как if (a=0) and (b=0), в этом смысле полезнее в десятки раз, чем if a=(0 and b)>0, или как-то ещё не по обычным ожиданиям.
Re[7]: Чем плох Паскаль?
От: AlexRK  
Дата: 14.06.19 11:54
Оценка: :)
Здравствуйте, netch80, Вы писали:

N>компилируется без проблем.


Да? Запамятовал. Впрочем, дела это не меняет — do/while образует блок, абсолютно как и в паскале. А while — не образует.

N>Все описанные тобой проблемы это запреты на разные хаки, а простое прямолинейное решение как раз не мешается с этим. А в Паскале надо даже написав hello world помнить, что тут именно '.', а не ';'


Речь не о хаках, а о том, что main — не обычная функция. И лучше это понимать, чем нет. Выражать отличие синтаксически — закреплять понимание.

N>>>что and и or почему-то приоритетнее сравнений

ARK>>А почему должно быть наоборот?

N>Потому что приоритеты операций придуманы не от балды, а чтобы упростить наиболее типовое применение.

N>Если бы сложение было приоритетнее умножения, и надо было бы a+b*c писать a+(b*c), чтобы его не поняли как (a+b)*c, то аналогичные жалобы были бы и тут.
N>Запись типа if a=0 and b>0, понимаемая как if (a=0) and (b=0), в этом смысле полезнее в десятки раз, чем if a=(0 and b)>0, или как-то ещё не по обычным ожиданиям.

В этом есть резон, но я считаю, что приоритеты вообще не нужны. Всегда явно выделяю скобками все операции.
Re[8]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 12:40
Оценка: +1
Здравствуйте, AlexRK, Вы писали:

N>>компилируется без проблем.

ARK>Да? Запамятовал. Впрочем, дела это не меняет — do/while образует блок, абсолютно как и в паскале.

Нет, не образует.

do
  x();
  y();
while (z);


не скомпилируется.

N>>Все описанные тобой проблемы это запреты на разные хаки, а простое прямолинейное решение как раз не мешается с этим. А в Паскале надо даже написав hello world помнить, что тут именно '.', а не ';'

ARK>Речь не о хаках, а о том, что main — не обычная функция. И лучше это понимать, чем нет. Выражать отличие синтаксически — закреплять понимание.

Что, много кто пытается вызвать main рекурсивно? Что-то ни разу не видел.

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


Боюсь представить себе, как выглядит твой код и как на это ругаются коллеги.
Рекомендовать всем такое, увы, не могу.
Re: Чем плох Паскаль?
От: borga  
Дата: 14.06.19 13:17
Оценка: +1
Здравствуйте, Cicero, Вы писали:

Читая ответы коллег у меня возникает странное чувство непонимания.

Если это касается школы: вы реально считаете что там вот это все о чем Вы спорите важно?
Там ИМХО все изучается на элементарном уровне.
Какие указатели? Вы о чем?

Что же касается более продвинутого уровня.
Вам вот реально важно begin/end или {}?
Re[4]: Чем плох Паскаль?
От: ksandro Россия  
Дата: 14.06.19 15:59
Оценка: +1
Здравствуйте, Джеффри, Вы писали:

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


K>>Чувствую себя старым... Народ уже забыл что такое Delphi...

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

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

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

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

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

Д>А так из реальных недостатков — он вроде платный был раньше? не помню была раньше какая-то бесплатная education / developer версия?

Во времена самой большой популярности Дельфи в бывшем СССР это мало кого волновало вообще.
Re[8]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 15.06.19 04:54
Оценка: +1
Здравствуйте, 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> С точки зрения промышленного программирования с указателями в С — полная катастрофа с безопасностью, но для обучения как раз идеально.


Не-а. Чтобы понять простую идею "указатель это адрес", это всё не нужно.
Чтобы понять арифметику указателей — тоже. Её по любому надо явно объяснить, и этого достаточно.
Re[10]: Чем плох Паскаль?
От: AlexRK  
Дата: 16.06.19 03:59
Оценка: -1
Здравствуйте, netch80, Вы писали:

N>Пусть по одной ветке тип получает значение complex<float>, по другой double, по третьей — string.

N>Какой тип будем дедуцировать?

Вопрос не ко мне, но очевидно же, что compile error.
Re[8]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 16.06.19 06:36
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

_>>И вынесенные объявления.

C>Уродство. Чистейшее уродство из-за повреждения моска Паскалем.
Видимо вы уже не способны мыслить. И не видите очевидного.

C>Я уж не говорю, что все определения нынче легко можно заменить на "auto". В данном случае явный тип переменной по месту служит дополнительной документацией (чтобы не нужно было IDE напрягать), тогда как в варианте "мессиво в начале функции" он полностью бесполезен.


Я же об этом и говорю должно быть с auto и выглядеть так:
llvm::Value *
ItaniumCXXABI::EmitMemberPointerComparison(CodeGenFunction &CGF,
                                           llvm::Value *L,
                                           llvm::Value *R,
                                           const MemberPointerType *MPT,
                                           bool Inequality) {
  CGBuilderTy &Builder = CGF.Builder;
  auto Eq, And, Or, LPtr, RPtr, PtrEq, Zero, EqZero LAdj, RAdj, AdjEq, One, OrAdj, OrAdjAnd1, OrAdjAnd1EqZero, Result;

  if (Inequality) {
    Eq = llvm::ICmpInst::ICMP_NE;
    And = llvm::Instruction::Or;
    Or = llvm::Instruction::And;
  } else {
    Eq = llvm::ICmpInst::ICMP_EQ;
    And = llvm::Instruction::And;
    Or = llvm::Instruction::Or;
  }

  // Member data pointers are easy because there's a unique null
  // value, so it just comes down to bitwise equality.
  if (MPT->isMemberDataPointer())
    return Builder.CreateICmp(Eq, L, R);


  // For member function pointers, the tautologies are more complex.
  // The Itanium tautology is:
  //   (L == R) <==> (L.ptr == R.ptr && (L.ptr == 0 || L.adj == R.adj))
  // The ARM tautology is:
  //   (L == R) <==> (L.ptr == R.ptr &&
  //                  (L.adj == R.adj ||
  //                   (L.ptr == 0 && ((L.adj|R.adj) & 1) == 0)))
  // The inequality tautologies have exactly the same structure, except
  // applying De Morgan's laws.

  LPtr = Builder.CreateExtractValue(L, 0, "lhs.memptr.ptr");
  RPtr = Builder.CreateExtractValue(R, 0, "rhs.memptr.ptr");

  // This condition tests whether L.ptr == R.ptr.  This must always be
  // true for equality to hold.
  PtrEq = Builder.CreateICmp(Eq, LPtr, RPtr, "cmp.ptr");

  // This condition, together with the assumption that L.ptr == R.ptr,
  // tests whether the pointers are both null.  ARM imposes an extra
  // condition.
  Zero = llvm::Constant::getNullValue(LPtr->getType());
  EqZero = Builder.CreateICmp(Eq, LPtr, Zero, "cmp.ptr.null");

  // This condition tests whether L.adj == R.adj.  If this isn't
  // true, the pointers are unequal unless they're both null.
  LAdj = Builder.CreateExtractValue(L, 1, "lhs.memptr.adj");
  RAdj = Builder.CreateExtractValue(R, 1, "rhs.memptr.adj");
  AdjEq = Builder.CreateICmp(Eq, LAdj, RAdj, "cmp.adj");

  // Null member function pointers on ARM clear the low bit of Adj,
  // so the zero condition has to check that neither low bit is set.
  if (UseARMMethodPtrABI) {
    One = llvm::ConstantInt::get(LPtr->getType(), 1);

    // Compute (l.adj | r.adj) & 1 and test it against zero.
    OrAdj = Builder.CreateOr(LAdj, RAdj, "or.adj");
    OrAdjAnd1 = Builder.CreateAnd(OrAdj, One);
    OrAdjAnd1EqZero = Builder.CreateICmp(Eq, OrAdjAnd1, Zero,
                                                      "cmp.or.adj");
    EqZero = Builder.CreateBinOp(And, EqZero, OrAdjAnd1EqZero);
  }

  // Tie together all our conditions.
  Result = Builder.CreateBinOp(Or, EqZero, AdjEq);
  Result = Builder.CreateBinOp(And, PtrEq, Result,
                               Inequality ? "memptr.ne" : "memptr.eq");
  return Result;
}
Re[4]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 16.06.19 06:41
Оценка: +1
Здравствуйте, Mr.Delphist, Вы писали:

C>>Не подходит. После Паскаля приходится потом долго вправлять моск в правильную сторону.

MD>Простите, а что за "неправильная" такая сторона у Паскаля?
Куча вредных идей типа "выход из функции только один", непонимание системных концепций (указатели) и в то же время незнакомство с более высокоуровневыми понятиями (векторы, хэш-карты, объекты, управление зависимостями, ...)

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

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

MD>Но берут-то почему?
Кого где берут?
Sapienti sat!
Re[3]: Чем плох Паскаль?
От: pagid Россия  
Дата: 16.06.19 07:17
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>А зачем?

А зачем в школе предмет — информатика? Может и не нужен но если нужен, то как минимум про байты с битами придется рассказать, про организацию памяти, в простейшем виде, с линейной адресацией наверно тоже. Можно конечно предполагать, что библиотекарше и секретарше достаточно будет знать почти человеческий SQL Excel Питон. Но он точно школьку нужен больше, чем байт с битом?
Re[8]: Чем плох Паскаль?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.06.19 13:48
Оценка: -1
Здравствуйте, Sharowarsheg, Вы писали:


S>По математике, может быть и да. А вот будущим билолгам с химиками хочется не вот этой твоей нуднятины с обработкой результатов, а интересного. Жуков там на иголки насаживать, бомбы делать, вот это всё. Обработку им сувать сейчас — отобьешь интерес навсегда.


Ну в итоге то вся работа будет связана именно с обработкой данных. И нужно не только жуков на иголки насаживать.
Программирование это инструмент. Например нельзя изучать физику без высшей математики. Ибо зазубривая формулы не зная откуда они берутся, тоже отбивает всю охоту.
А вот зная постановку задачи и её решение все становится значительно проще.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 16.06.2019 17:37 Serginio1 . Предыдущая версия .
Re: Чем плох Паскаль?
От: scf  
Дата: 16.06.19 15:05
Оценка: +1
Здравствуйте, Cicero, Вы писали:

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

C>Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!

C>Давайте обсудим и выработаем обоснованные аргументы.


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

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

Этого списка достаточно, чтобы загрузить школьников до 11 класса включительно. Надеюсь, никто не будет спорить, что а) всё перечисленное нужно и б) никакие парадигмы и библиотеки для этого не нужны.

Теперь о плюсах Паскаля:
— программы не требуют ни `public static void main`, ни хитрого кода инициализации консоли/окна/графики
— простой удобный интерактивный отладчик, мнгновенная компиляция
— строгий структурированный синтаксис на английском языке, без лишних сокращений типа фигурных скобок и навязанных идиом типа значимых отступов
— строгая типизация
— достаточно низкоуровневый, чтобы рассказывать школьникам про байты, биты, непрерывные многомерные массивы и организацию памяти

И о минусах:

25х80, текстовый интерфейс и запуск через dosbox — некруто.
Re[7]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 16:12
Оценка: +1
Здравствуйте, kov_serg, Вы писали:

M>>Я бы не сказал, что это шум.

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

Зачем вообще нужны такие ограничения?
Предварительное объявление переменных — это ранняя форма защитного костыля против проблем с опечатками в переменных, и средство задать тип переменной.
Для своего времени было полезное и ценное решение. Для сейчас — нет. Есть другие средства получше.
Тем более когда речь про разнообразные промежуточные константные значения.

Я бы ещё понял, если бы "ограничениями" было названо, например, неиспользование floating point — ну поставил атрибут на блок кода или целую функцию, и оно не пускает такое в компиляцию — но просто на список переменных... бррр...

M>>Кстати, про RAII слышал?

_>Если вам говорили что RAII вершина управления ресурсами то от вас многое утаили.

А списки var, значит, вершина?
Не понимаю, зачем это замечание.

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

M>>И зачем это нужно?
_>Незнаю но многие упорно хотят видеть где переменная впервые использеутся. С этим спокойно спраиться IDE просто подсвечивая имя под курсором по всему тексту.

Функция "перейти к точке определения" присутствует во всех нормальных современных IDE.

_>
  Скрытый текст
Image: glCtE2Y.png

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

Ну так всё-таки зачем их всех называть предварительно?

_>...

M>>Какой замечательный код, который позволяет легко нарваться на неинициализированную переменную
_>Как раз нет. Посмотрите язык zig если ваша переменная должна быть не инициализированны то это надо объявить явно иначе вообще не компилируется.

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

По нормальному, да, компилятор способен отработать и вариант со всеми именами с типами вначале, и посреди кода. Но зачем дублировать?
Re[9]: Чем плох Паскаль?
От: pagid Россия  
Дата: 16.06.19 16:48
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

S> Программирование это инструмент. Например нельзя изучать математику без высшей математики.

Значит школьники зря математику на уроках учат. Им бы сначала высшую преподнести, тогда можно и школьной заниматься. Или ты что-то другое называешь изучением, а может быть и математикой
Re[6]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 18.06.19 18:13
Оценка: +1
Здравствуйте, pagid, Вы писали:

MAG>>Нахера вот это все нужно знать школьнику? Почему никого не удивляет, что школьникам дают арифметику и алгебру, а не матанализ и теорию чисел. Но как только речь заходит о программировании, нет, подавайте в школе организацию памяти.

P>Так это как раз и есть арифметика, а не матанализ.
Организация памяти — это скорее изучение математики с теории множеств и арифметики Пеано.

Да, организация памяти — это очень базовая вещь, но её тупо можно пропустить.
Sapienti sat!
Re[4]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 18.06.19 18:54
Оценка: +1
Здравствуйте, Mr.Delphist, Вы писали:

C>>Синтаксис не строгий.

MD>Тогда давайте пример production-языка с действительно строгим синтаксисом.
Go, Rust, даже JavaScript.

C>>Не строгая.

MD>Эммм... А можно тогда пример действительно строгой типизации? В каком языке? Ну, не считая адской экзотики. Ибо вот чего-чего, а строгости типов Паскаля мне время от времени не хватало во всех этих Си-подобных.
Из современных — Go, Rust, Elm.

MD>На всякий случай, напомню, что в Паскале: https://ideone.com/nYueOe

MD>
MD>var a: array[1..10] of integer;
MD>var b: array[1..10] of integer;
MD>...
MD>a := b; { не скомпилируется }
MD>

И где тут строгость? Просто идиотское ограничение — оба массива идентичны.
Sapienti sat!
Re[8]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 19.06.19 08:46
Оценка: +1
Здравствуйте, AlexRK, Вы писали:

MD>>>1) Для новичка эти идеи типа "один вход — один выход" очень даже полезные.

C>>Ничем оно не полезное, вообще.
ARK>Почему же, один выход проще, чем несколько. Вообще, ретурны, рассеянные где попало в теле функции — это нехорошо. Мешает рассуждениям о программе и часто является признаком говнокода.
Рассуждениям часто мешают множественные вложенные if'ы и флаги вида "needExit", которые появляются в противном случае.

C>>Да, так как от паскалистов в итоге ноль софта осталось.

ARK>Total Commander!
Так оно померло...

ARK>А что насчет Golang? В нем отсутствие генериков не является препятствием реальному программированию? Но зато в паскале отсутствие генериков сразу ставит крест на обучении. Верно?

В Golang есть генерики — стандартные векторы и карты. Этим часто можно обойтись. Но да, ждём настоящих generic'ов.
Sapienti sat!
Re[7]: Чем плох Паскаль?
От: AlexRK  
Дата: 19.06.19 08:56
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

ARK>>Почему в паскале синтаксис не строгий, а в Go, Rust и JavaScript — строгий?

C>Потому, что в Паскале в нём нет стройной логики — куча непонятных исключений и ограничений. В Rust/Go/JS есть логика, хотя в случае JS она слегка наркоманская.

Не придирки ради, а токмо интереса для: какие, например, исключения и ограничения в паскале (а в Rust/Go их нет)? Определения переменных в секции "var"?

ARK>>Почему в паскале типизация не строгая, а в Go и Rust — строгая?

C>Ну начнём с того, что в Паскале в принципе нет generic'ов. Т.е. реальный код не сможет использовать обобщённые алгоритмы и контейнеры.

Но в Go тоже нет генериков, при этом он заявлен как пример строгой типизации.

C>Но даже если на это закрыть глаза, то в стандартном Паскале нет проверки численных переполнений, хотя есть ограниченные типы. В некоторых реализациях эти проверки таки добавили.


По-моему, это было только в самой первой версии. ИМХО, когда сейчас говорят о паскале, имеют в виду что-то более современное (хотя бы трубопаскаль, или фри).
Re[8]: Чем плох Паскаль?
От: elmal  
Дата: 19.06.19 08:57
Оценка: +1
Здравствуйте, AlexRK, Вы писали:

ARK>Почему же, один выход проще, чем несколько. Вообще, ретурны, рассеянные где попало в теле функции — это нехорошо. Мешает рассуждениям о программе и часто является признаком говнокода.

Вот только когда вместо дополнительного ретурна из двух циклов сразу вместо этого фигачат переменную флаг, и ее постоянно проверяют на каждой итерации цикла — это на порядок больший говнокод, чем несколько возвратов. Ибо лишний код на ровном месте, куча уровней вложенности на ровном месте и раздувание сложности на ровном месте. Вот к таким флагам студенты и школьники привыкают и к логике на дополнительных if с уровнями вложенности, потом хрен отучишь. Да, действительно от множества return в коде желательно избавляться. Но совсем не теми средствами, которые де факто стандарт в паскале. И это не догма, есть случаи, когда дополнительный return наоборот добавляем читаемости.
Re[8]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 19.06.19 19:30
Оценка: :)
Здравствуйте, Mr.Delphist, Вы писали:

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

MD>Имя, сестра! Имя! (ц)
Go (modules), Rust (Cargo), Ruby (Gems), Python (PIP), Java (Maven).

MD>Как именно управляется зависимость в C++ STL?

С++ — это не современный язык.
Sapienti sat!
Re[6]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.06.19 06:16
Оценка: +1
Здравствуйте, Mr.Delphist, Вы писали:

C>>И где тут строгость? Просто идиотское ограничение — оба массива идентичны.

MD>Похоже, насчёт строгой типизации нам говорить ещё рано

Верно замечено — вам, похоже, таки рано.

Там, где не рано, делают, например, так (близко к Ada)


type real = float;

type temperature = new float;

type altitude = new float;

type foo = struct {
  bar: integer;
  baz: float;
};

type buka = foo;

type ziuka = new foo;


и с этого момента buka — просто алиас для foo, а ziuka — намеренно отдельный тип, все имплицитные соответствия, конверсии и присвоения запрещены, то же для температуры (ей высоту просто так не присвоишь, матчинг функции не будет происходить, и так далее).

А теперь сюрприииз — в том самом Go, в котором вы увидели только duck typing, то же самое:

type real = float
type altitude float
type temperature float

type foo struct {
  bar int
  baz float
}

type buka = foo
type ziuka foo


с тем же результатом — buka идентичен foo (алиас для него), real = float во всём использовании, а вот ziuka, altitude и temperature отделены.

А изображать "строгую типизацию" разделением типов просто из-за идентичного объявления массива в двух местах... ну да, Вирту в Модуле такое приснилось. Только повторять это на трезвую голову никто не хочет.

MD> Синтаксис JS строже чем у Pascal... Разрешите тогда упомянуть классику: https://www.destroyallsoftware.com/talks/wat


Я не защищаю тут позицию Cyberaxʼа, но вы синтаксис от семантики не отличаете.

С синтаксисом у JS, таки, есть проблемы, но в другом, например:

  return
    1;


он вернёт null.
В ролике про WAT про это ни слова, там другие хохмы (да, реальные и грустные).

Кстати, ещё один из ваших мифов про Go:

MD> Go — основан на duck-typing (ещё бы, наследования-то не завезли)


Завезли:

A field declared with a type but no explicit field name is called an embedded field. An embedded field must be specified as a type name T or as a pointer to a non-interface type name *T, and T itself may not be a pointer type.

A field or method f of an embedded field in a struct x is called promoted if x.f is a legal selector that denotes that field or method f.

Given a struct type S and a defined type T, promoted methods are included in the method set of the struct as follows:

If S contains an embedded field T, the method sets of S and *S both include promoted methods with receiver T. The method set of *S also includes promoted methods with receiver *T.
If S contains an embedded field *T, the method sets of S and *S both include promoted methods with receiver T or *T.


И это наследование ещё и множественное. Вот виртуальных функций в нём, да, нет и не предвидится, поэтому по сравнению с традиционным наследованием типа C++/Java/etc. оно инвалидное.
Re[14]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.06.19 14:39
Оценка: +1
Здравствуйте, pagid, Вы писали:

N>>Например, берём Unix API:

N>>int open(аргументы);
N>>реально два значения — дескриптор и код ошибки (который поступает в errno).
P>Тут есть своя логика, примитивная конечно.
P>Признак ошибки -1 в возвращаемом значении, если ошибки нет, то её код не нужен совсем.

Это просто такой стиль проекции ответа {ok, Handle} | {error, Error}.
Точно так же как значение NULL для указателя (Хоар плачется, что это была ошибка, но на момент введения это было отличным выходом).
И это не единственный вариант стиля.
Например, возврат 0 из read() это вариант показать ошибку EOF. Просто EOF как бы принято считать не совсем ошибкой, потому оно не выделяется.
А вот в раннем SunOS nonblocking I/O был флаг FIOASYNC, который давал при отсутствии данных в данный момент — 0 вместо {-1, EAGAIN}, и путался с честным EOF — из-за чего его и отменили.
А могли сделать наоборот — 0 как признак ошибки вместо реального ответа, а EOF внести в errno. Тоже метод, хоть и менее практично.

N>>int pipe(int fildes[2]);

N>>три значения — два дескриптора и код ошибки.
N>>int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
N>>три выходных — код ошибки, сокет и адрес.
N>>И так далее.
N>>Windows? То же самое: у до чёрта функций код ошибки передаётся боковым каналом, его надо доставать через GetLastError(). И аналог такого accept() есть, и многое другое.

P>Это все забавно, но что получается, что языкам, где не предусмотрено возвращение нескольких значений путь в эту новую "правильную" ОС с "правильными" системными вызовами будет закрыт? Или придется лепить страшные костыли.


Придётся лепить ровно такие же костыли, как и сейчас: заполнение нескольких раздельных значений по указателям, заполнение структуры по указателям, возврат структуры явным образом (на уровне конвенции превращающемся опять же в указатель на структуру). Ничего нового.
Отредактировано 21.06.2019 4:42 netch80 . Предыдущая версия .
Re[8]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 20.06.19 19:05
Оценка: +1
Здравствуйте, AlexRK, Вы писали:

ARK>Не придирки ради, а токмо интереса для: какие, например, исключения и ограничения в паскале (а в Rust/Go их нет)? Определения переменных в секции "var"?

Совершенно странный ввод-вывод, который нельзя выразить в виде обычных функций/процедур, например.

C>>Но даже если на это закрыть глаза, то в стандартном Паскале нет проверки численных переполнений, хотя есть ограниченные типы. В некоторых реализациях эти проверки таки добавили.

ARK>По-моему, это было только в самой первой версии.
Это в ИСО-шном стандарте так.

ARK>ИМХО, когда сейчас говорят о паскале, имеют в виду что-то более современное (хотя бы трубопаскаль, или фри).

Но они все значительно сложнее.
Sapienti sat!
Re[2]: Чем плох Паскаль?
От: MamutArGud  
Дата: 20.06.19 19:26
Оценка: +1
LVV>В российских школах — как второй.
LVV>Или параллельно с русскоязычным.

А есть хоть один нормальный русскоязычный ЯП?

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


Даже! Кто такой, почему мы должны ему безоговорочно верить?

LVV>В своем учебнике по информатике для профильных классов он так и написал — параллельно.

LVV>Слева — КуМир, справа — Паскаль.

Это тот самый кумир, который алг нач цел вещ все кон? За что?

алг qSort(аргрез целтаб A[1:5], арг цел iStart, iEnd)
нач
  цел L, R, c, X
  если iStart >= iEnd то выход все
  L:= iStart; R:= iEnd;
  X:= A[div(L+R,2)]
  
  нц пока L <= R
    нц пока A[L] < X; L:= L+1 кц
    нц пока A[R] > X; R:= R-1 кц

    если L <= R то
      c:= A[L]; A[L]:= A[R]; A[R]:= c
      L:= L+1; R:= R-1
    все
  кц

  qSort(A, iStart, R)
  qSort(A, L, iEnd)
кон


За что вы так ненавидите детей?

LVV>Если кто скажет, что они развиваются, а паскаль — нет, то это ерунда.

LVV>Смотрите Оберон и Зоннон.

Здесь мы на них смотрели. Много раз.

LVV>Фактически — нет конторы, которая поддерживала бы паскаль на рынке.


«Паскаль не развивается — это ерунда», но одновременно «нет конторы, которая поддерживала бы паскаль»
Re[3]: Чем плох Паскаль?
От: __kot2 США  
Дата: 22.06.19 16:38
Оценка: -1
Здравствуйте, pagid, Вы писали:
__>>ну, можно ему в универе учить. а зачем? потом все равно что-то другое учить придется
P>Так любое другое учить будет проще, а это "другое" может оказаться очень разным.
дело во временных затратах.
нужен например тебе для работы, русский язык. а тебе говорят — ты сначала изучи болгарский, украинский и белорусский и тогда, когда будешь русский, наконец учить, будет проще и будешь глубже его понимать. так-то оно так, но все-таки это просто сильно дольше получается
http://kotkotius.blogspot.com/
Re[2]: Чем плох Паскаль?
От: __kot2 США  
Дата: 22.06.19 22:32
Оценка: -1
Здравствуйте, Michael7, Вы писали:
M>Но такое ощущение, что разные люди имели ввиду разный Паскаль. Виртовский, Турбо-Паскаль, ранние версии Delphi, современные версии Delphi и FreePascal — это все очень разные языки. В Delphi в 2009 году вообще даже дженерики завезли.
все одинакого бесполезны. просто один чуть бесполезнее другого (сам я в школе учил и турбопаскаль и делфи)

M>У меня такое ощущение сейчас, что программирование школьникам сейчас невозможно адекватно преподавать. Потому что все простое сейчас стало слишком оторвано от практически полезного. В эпоху турбо-паскаля на нем можно было даже коммерческие программы писать.

ну почему — питон и жабоскрипт ва идеальных языка как раз для этого подходящих. на одном можно писать гуй и всякие примочки прикольные, на втором — даже что-то околонаучное можно сделать и без всякого знания ООП
http://kotkotius.blogspot.com/
Re[4]: Чем плох Паскаль?
От: __kot2 США  
Дата: 23.06.19 13:40
Оценка: +1
Здравствуйте, AlexRK, Вы писали:
ARK>"Идеальных". Жабаскрипт — это всестороннее уродство, которое для обучения просто вредно. Питон динамически типизирован и, как следствие, программы на нем подвержены ошибкам на этапе выполнения, что для обучения тоже скверно.
идеальный язык это тот, который заинтересует ученика
а не тот, который замечательный и формальный и от которого тащится только препод, но на нем ничего нельзя сделать
http://kotkotius.blogspot.com/
Re[5]: Чем плох Паскаль?
От: Лось Чтостряслось Польша  
Дата: 30.06.19 20:59
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>При переходе наоборот — тоже.

ну в этом случае они явно есть, что уже плюс
русофобия сушит мозг
Re[4]: Чем плох Паскаль?
От: VladiCh Ниоткуда  
Дата: 02.07.19 03:38
Оценка: +1
Здравствуйте, Александр Кузнецов, Вы писали:

АК>Здравствуйте, alpha21264, Вы писали:


I>>>зачем обучать мёртвому языку ?


A>>В инязе обучение английскому начинают с латыни. Ну это так, в качестве примера.


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

АК>А вот начинать учить английский с, например, старонорвежского, я бы всё-таки не советовал.

Старонорвежский был бы по логике ближе, следуя вашей логике, т.к. он гораздо ближе к староанглийскому чем латынь.
Английский если что ни разу не от латыни произошел. Заимствовал кучу слов, это да.
Ну так и Паскаль тоже многое заимствовал из более ранних языков, совершенно новых концепций в любом современном языке не сыщешь днем с огнем.
Также как и из Паскаля заимствований достаточно. Вообще практика использования учебного языка вместо промышленного имеет право на жизнь мне кажется.
Re: Чем плох Паскаль?
От: Marty Пират  
Дата: 16.09.19 20:27
Оценка: +1
Здравствуйте, Cicero, Вы писали:

C>Выскажу свое мнение:

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

Гавно, а не язык. После асма Z80 меня паскалю пару лет в тереме учили. Книжка по паскалю, без которой было не обойтись, была в 4е раза толще книжки по асму. Сишечка, а потом сипипишечка потом мною были восприняты как глоток свежего воздуха (это я про TC 1.0 и BC3.1 vs TP5.5)


C>Причем если не позволяет "железо" более современные версии вполне подойдет и Turbo Pascal 5.5.


Современное железно как раз уже не позволяет запускать это говно мамонта — в винде дос подсистему выпилили, это еще в семерке, лет 10 назад делал проект под Турбо Си 1.0 — пришлось ставить DosBox


C>На Turbo Pascal вполне можно обучать и элементы ООП.


Буханка.jpg


C>Почему:

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

Это не так. Я так и не запомнил, какие знаки препинания где и когда ставить, хорошо, среда подсказывала (если что, я несколько лет писал на делфях, потом в той конторе начал билдер юзать, и начальство писалось от восторга, насколько я стал быстрее). На C++ я открываю ideone.com и пишу код, который сразу компилируется


C>ИМХО это научит контролировать код более строго.


Или не научит

Сишечка, а потом сипипишечка — научили меня строго контролировать то, что я пишу. А Паскаль — он не учит, он сам пытается строго контролировать. Получается весьма хреново. Угробище этот ваш Паскаль
Вам как-бы показали сцыкливое мурло российской оппозиции — вот оно
Автор: Министр Промышленности
Дата: 17.10 22:57
!
Re: Чем плох Паскаль?
От: MasterZiv СССР  
Дата: 24.09.19 09:03
Оценка: +1
Здравствуйте, Cicero, Вы писали:

C>Очень часто это слышу: Паскаль(иногда конкретизируют: Turbo Pascal)


Все, все, ВСЕ популярные современные языки программирования базируются синтаксически на
синтаксисе языка С. Исключение -- разве что Python.
Ни о чём не говорит?
Вот, поехали далее.

На Паскаль НЕТ технологических стандартов. Он везде разный.
(точнее, стандарты есть, но их 5 разных)
По сути языка "Паскаль" не существует, есть сонм паскалеподобных языков, каждый со своими особенностями.
Что ты изучать собираешься?
Поехали дальше.

В Паскале НЕТ ООП. даже нет объектного подхода.
В Паскале нет встроенных типов данных every language must have: vector, map, list.
В Паскале нет исключений.
Переварил?

Поехали дальше.

Единственный современный компилятор Паскаля что я знаю -- Лазарус.

Ну и уж на последок -- поищи работу по Паскаль на hh.ru, посчитай, сколько найдёшь.
Re[2]: Чем плох Паскаль?
От: MasterZiv СССР  
Дата: 24.09.19 09:12
Оценка: -1
Здравствуйте, _ABC_, Вы писали:

_AB>А почему ты решил, что это важнейшая задача первоначального обучения в школе?


СОГЛАСЕН! Самая главная задача -- УВЛЕЧЬ ребёнка этим!

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


+++

P.S. Паскаль -- говно. Всегда был говном и останется говном. Вирт дебил. Дай ему Бог счастья на пенсии.
Re[3]: Чем плох Паскаль?
От: MasterZiv СССР  
Дата: 24.09.19 09:17
Оценка: -1
Здравствуйте, Pzz, Вы писали:

C>>В современном варианте было бы лучше что-то типа Питона с графической средой. Или как вариант: https://www.apple.com/swift/playgrounds/ — лучшее, что я вообще видел для детей.


Pzz>Мне кажется, использование в качестве первого языка, языка с динамической типизацией, уродует головной мозг человека навсегда.


Нет. Даёт лёгкость.
Re[3]: Чем плох Паскаль?
От: MasterZiv СССР  
Дата: 24.09.19 09:20
Оценка: +1
Здравствуйте, kov_serg, Вы писали:


_>Почему некоторые люди считают что объявление переменных по месту это хорошо? Чем плохо заранее объявить что понадобиться, а не равномерно размызвать безполезное гавно по коду.


Потому что удобно её находить, она всегда по ходу чтения и выполнения кода обнаруживается.
Вот это мы сделали -- И ЗАПОМНИМ РЕЗУЛЬТАТ.

Сравни с

МЫ ПИШЕМ ФУНКЦИЮ ПОИСКА В СТРОКЕ ПОДСТРОКИ

МЫ БУДЕМ ЗАПОМИНАТЬ:
текущий индекс символа строки q, как целое
текущий символ строки как символ

...


А ТЕПЕРЬ НАЧНЕМ!
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
а тут мы увеличим q !
Re[5]: Чем плох Паскаль?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 26.09.19 15:30
Оценка: +1
Здравствуйте, Vlad_SP, Вы писали:

V_S>Здравствуйте, Sinclair,


S>> Отлично. А на кой чёрт программисту баскетбол, или, не побоюсь этого слова, Русский Язык?


V_S>А вот если провести аналогию с "реальным промышленным программированием" — ну на кой черт программисту реальные тренировки по методикам мастерской команды (уровня сборной страны) по баскетболу? (Да у него после этих тренировок не останется сил программировать! И времени тоже.) А сколько программистов хотя бы слышали про "глокую куздру"?

Как-то вы криво проводите аналогию. Так-то в школе дают совершенно полноценные правила баскетбола. Да, там нет ежедневных тренировок по 6 часов — но сам баскетбол ровно такой же, как в NBA.
И это я ещё не говорю про волейбол, прыжки через козла, бег на лыжах, и прочее.

V_S>Если программист будет играть в баскетбол в составе дворовой команды на свежем воздухе и ему это интересно ради собственного развлечения — да на здоровье! Та же самая ситуация со школьниками — если школьнику это интересно, и он готов этим заниматься — да на здоровье!

V_S>Имхо тут не надо смешивать общеобразовательно-обзорный уровень и уровень профессиональный.
Ну, с точки зрения баскетбольной аналогии, Паскаль — это примерно как дать ребёнку мячик, и обучить стучать им об пол. А вот все вот эти "бросок в два шага", "передача", "обманное движение", да и вообще бросок в кольцо — этого не надо, это их в профессиональной сборной научат.

V_S>Ой! Вот это уже натягивание совы на глобус. Умеет программировать Тимченко? Ротенберг? Алекперов? Потанин?

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

V_S>Ну ланна, не будем брать миллионеров. Вот был такой Жорес Алферов — академик, нобелевский лауреат и все такое. Умел программировать? А скажем известный писатель Даниил Гранин?

Вот кому известен Гранин — я не знаю, а вот такой писатель, как Леонид Каганов — да.
Алфёров, я так думаю, о программировании имел вполне себе неплохое представление.

V_S>Ну хорошо, возьмем "простых людей". Вот моя теща — доктор наук (в самом деле!), катается себе по Европам с Америками с докладами, ее реально ценят зарубежные ученые (не британские учоные — почувствуйте разницу!). Вполне себе состоявшийся в жизни человек. Но вот в программировании — полный ноль. Хотя компьютер освоила в уже весьма серьезном возрасте и очень даже успешно. Как же она умудряется "выдерживать требования времени" без программирования? А признание и авторитет в мировом научном сообществе — это именно "выдерживание требований времени", КМК.

Отож. Кроме этого, она наверняка совершенно не в состоянии выполнить обыкновенный трёхочковый бросок, или отбить волейбольную подачу. Так ведь? Ну и нахрена тогда она 10 лет в школе дважды в неделю занималась этим всем?
Давайте уберём физру! Пусть будет факультативом. Давайте пройдёмся по всем предметам и уберём все те, которых не знает ваша тёща. Ведь у нас перед глазами живой пример — человек обошёлся без них.
Потом возьмём Жореса Алфёрова, и выкинем из программы всё, чего он не знал на момент выполнения работы, за которую получил Нобелевку. Если что-то останется и после этого, то алгоритм понятен: берём ещё кого-то (например, Майю Плисецкую), и как дважды два четыре доказываем, что можно прекрасно устроиться ещё без чего-то.

V_S>Есть такое явление — профессиональная деформация. Условно говоря, столяр в любом предмете видит молоток. То же и с программистами.



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

S>>Вот примерно как я себе всё это вижу.

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

V_S>Причем именно "курс информатики", а не конкретно "программирование" (ну или там "шахматы", как сейчас модно) или конкретно Паскаль. В рамках этого курса можно и нужно дать школьникам понятие об алгоритме, пару-тройку простейших программ и т.п., и как это можно использовать (а можно и не использовать) в жизни. Тут уж хоть Паскаль, хоть Бейсик, хоть черт в ступе, — все хорошо. А уж всякие там "кортежи", "функторы" и иже с ними — для 99% школьников останутся пустым звуком на уроке. Кому интересно — добро пожаловать на факультатив.

Ок, отлично. Что за "простейшие программы" вы им собираетесь давать? Пока что я не вижу ничего такого, что вышло бы за уровень языка Лого.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[2]: Чем плох Паскаль?
От: Слава  
Дата: 13.06.19 15:24
Оценка:
Здравствуйте, Klikujiskaaan, Вы писали:

K>для подключения пупса к станку.


Простите, что?
Re[2]: Чем плох Паскаль?
От: Слава  
Дата: 13.06.19 19:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

C> работа с динамическими структурами вообще совсем никакая. Указатели в Паскале придумали какие-то извращенцы.


Что там не так с указалями? Арифметика указателей есть, кастуешь указатель к integer и стреляй себе в ногу делай с ним чего хочешь, потом обратно кастуй. Linked list сделать можно, дерево — тоже.
Re[3]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 13.06.19 19:53
Оценка:
Здравствуйте, Слава, Вы писали:

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


N>>Вирт, кстати, часть этих огрехов Pascal исправил, создав Modula.


С>Вы забыли ещё про синтаксический оверхед написать.


Ну тут уже я на нём не настаивал, вопрос спорный. Если речь про то, что begin — end надо было бы заменить на {}, то да, есть такое. Но в линии Modula, Ada сделали иначе — например,

if условие then
  тело
else
  тело2
end


что по-своему тоже неплохо, хотя и заметно иначе. Главное — что скобки обязательны. Скобки типа {} сейчас обязательны в Go, Swift, ещё много где, и это хорошо (для C++ на текущей работе их форсируют через uncrustify).

Если про стиль объявления переменных, то я, наоборот, категорически везде хотел бы видеть

var x: int;

или пусть даже

var x int // Go

чем

int x;

потому что последнее хорошо только в простых случаях, а в сложных оно приводит ко всяким хитровывернутым

typedef int (*foo)(double)[3];

которые ещё надо уметь разобрать "изнутри".

То же про необходимость слов procedure и function (хотя можно было бы всё таки сократить до function, func, fn).

Если про слово div, то опять таки я за принципиальное разделение двух видов деления на уровне синтаксиса.

Собственно из оверхеда остаётся только ":=" вместо "=". Ну да, с простым "=" было бы лучше (а особенно когда в сочетании со всякими +=).
Re[2]: Чем плох Паскаль?
От: Pzz Россия https://github.com/alexpevzner
Дата: 13.06.19 21:51
Оценка:
Здравствуйте, netch80, Вы писали:

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


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

Насколько я могу судить, причина тому — странная причудь Вирта оформлять вызов фукнции без аргументов в виде имени функции без скобок. Отсюда невозможность понять, если такая функция возвращает указатель на функцию, то что имеется ввиду, она сама или возвращаемое ей значение. Ну и как сомнительное решение этпй проблемы — отсутствие возможности вернуть указатель на функцию вообще.
Re[2]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 13.06.19 23:18
Оценка:
Здравствуйте, Don Reba, Вы писали:

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


В общеобразовательной школе? Хорошо если с доски спишут. Все, кто, учась в школе, могут понемногу участвовать в чём угодно, будут участвовать и так, и изучить два языка сразу — у этих не будет проблем. Остальным — чем проще, тем лучше.
Re: Чем плох Паскаль?
От: itmanager85  
Дата: 14.06.19 03:21
Оценка:
Здравствуйте, Cicero, Вы писали:

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

C>Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!

зачем обучать мёртвому языку ?

намного более актуальны c/c++ | Java | C# | PHP | MySql — после них хоть к станку (особенно если JS/JQuery добавить)
Re[3]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 04:51
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

S>Остальным — чем проще, тем лучше.


Именно поэтому Паскаль не подходит.
Re[4]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 14.06.19 04:52
Оценка:
Здравствуйте, netch80, Вы писали:

S>>Остальным — чем проще, тем лучше.


N>Именно поэтому Паскаль не подходит.


Да, но если сказать, давайте учить Бейсик в размере 1995 года, вой же будет ещё больше, не так ли?
Re[3]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 05:07
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Я б добавил к этому отсутствие возможности вернуть из функции указатель на функцию, при том что сами по себе такие указатели в языке есть.


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

Pzz>Насколько я могу судить, причина тому — странная причудь Вирта оформлять вызов фукнции без аргументов в виде имени функции без скобок. Отсюда невозможность понять, если такая функция возвращает указатель на функцию, то что имеется ввиду, она сама или возвращаемое ей значение. Ну и как сомнительное решение этпй проблемы — отсутствие возможности вернуть указатель на функцию вообще.


См. выше.
Да, после Вирта вроде никто такое не повторял (ну, Ruby позаимствовал, один на десятки новых языков).
Re[5]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 05:25
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

S>>>Остальным — чем проще, тем лучше.

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

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

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

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

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

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

5. Иметь обширную стандартную библиотеку (типа: тот же sort() должен быть; писать самому, конечно, хорошо для учёбы, но постоянно таскать за собой такую реализацию — нуегона) и репозиторий модулей на расширенные случаи (вплоть до чего-то типа CORBA клиента, не к ночи будь сказано).
Re[4]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 14.06.19 06:25
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


_>>Почему некоторые люди считают что объявление переменных по месту это хорошо? Чем плохо заранее объявить что понадобиться, а не равномерно размызвать безполезное гавно по коду.

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

C>Для программиста не пофиг, так как нельзя с первого взгляда увидеть, где переменная получает значение.

Так какие проблемы если так надо можно добавть резервное слово для первого присвоения скажем let. Оно будет единообразно указывать на первое определение.
C>Ну и с иммутабельностью по умолчанию оно тоже никак не дружит.
С какого перепоя. Компилятору всё равно где объявление. Так что оно будет работать как и работало.
SomeTypeWithLongNameAndAlotOfParametersAndNamespaces somevar;
auto v1,v2,v3,v4;
....

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
Отредактировано 14.06.2019 6:27 kov_serg . Предыдущая версия . Еще …
Отредактировано 14.06.2019 6:26 kov_serg . Предыдущая версия .
Re[6]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 14.06.19 06:48
Оценка:
Здравствуйте, T4r4sB, Вы писали:

C>>>Ну и с иммутабельностью по умолчанию оно тоже никак не дружит.

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

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

Мы просто объявляем переменную в начале блока.

TB>А ещё переменная может быть нужна лишь в одной из веток алгоритма. А в другой ветке нужна другая переменная того же типа. И в итоге получаем либо распухший список переменных в начале функции, либо вредную привычку вместо index для одной ветки и tmp для другой заводить одну specail_int и использовать её везде. Сейчас вы скажете, надо функции мельче делать?

Нет просто каждый блок может иметь свой список переменных.
Re[3]: Чем плох Паскаль?
От: elmal  
Дата: 14.06.19 07:02
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Почему некоторые люди считают что объявление переменных по месту это хорошо? Чем плохо заранее объявить что понадобиться, а не равномерно размызвать безполезное гавно по коду.

Плохо тем, что в результате большинство паскалистов лучше сдохнут и будут дико копипастить, но переменную не объявят . Ибо много букв, слишком сложно, проще скопипастить. А вообще, в современном мире именно классическая переменная — в большинстве случаев дурной тон и источник потенциальных ошибок. Рулит иммутабельность, соответственно рулят константы, которым нельзя повторно присвоить значения, а не переменные.
Re[7]: Чем плох Паскаль?
От: T4r4sB Россия  
Дата: 14.06.19 07:41
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Нет просто каждый блок может иметь свой список переменных.


Ну так вот, Паскаль в классическом виде с этим не оч. В Аде получше, знаю. Модули и Обероны не трогал, не скажу.
Re[8]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 14.06.19 07:54
Оценка:
Здравствуйте, T4r4sB, Вы писали:

_>>Нет просто каждый блок может иметь свой список переменных.


TB>Ну так вот, Паскаль в классическом виде с этим не оч. В Аде получше, знаю. Модули и Обероны не трогал, не скажу.

В паскале есть локальные функции. Чем не блоки?
Re[4]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 14.06.19 07:56
Оценка:
Здравствуйте, elmal, Вы писали:

_>>Почему некоторые люди считают что объявление переменных по месту это хорошо? Чем плохо заранее объявить что понадобиться, а не равномерно размызвать безполезное гавно по коду.

E>Плохо тем, что в результате большинство паскалистов лучше сдохнут и будут дико копипастить, но переменную не объявят . Ибо много букв, слишком сложно, проще скопипастить. А вообще, в современном мире именно классическая переменная — в большинстве случаев дурной тон и источник потенциальных ошибок. Рулит иммутабельность, соответственно рулят константы, которым нельзя повторно присвоить значения, а не переменные.
Да мне тоже erlang очень нравится. Но он не рулит, а просто инструмент.
Re[4]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 14.06.19 08:11
Оценка:
Здравствуйте, netch80, Вы писали:

N>Из живых на эту роль отлично подходит, например, Go (ближайший по духу), Java, C#, Python. Для системного уровня — C.

Есть же Perl!

N>Во-первых, должна быть. Учат чему-то полезному, и конкретный язык здесь, хоть и не первоочередная составляющая, но важная. А если ещё при обучении человек сразу включается в реальную работу и видит полезный выхлоп от своей работы — то это ещё больше работает на качество обучения.

Тогда Arduino и C++ — выхлоп, заинтересованность, можно пощупать результат, спалить что-нибудь, узнать что глючат не только программы, но и железо.
N>Во-вторых, тем более не должно быть цели учить тому, после чего надо заново переучиваться.
Так надо учить базовым вещам, на основе которых будет дальше легче изучать то что понадобится, а не те что меняются каждые пол года.
Алгоритмы, оценки сложности, линейную алгебру, вычислительную математику, цос, шаблоны проектирования, организацию вычислений, архитектуры процессоров, способы решения больших задач с учетом имеющихся ограничений, организацию больших проектов, как управлять группой безответсвенных, ленивых, раздолбаев и т.п.
Re[5]: Чем плох Паскаль?
От: elmal  
Дата: 14.06.19 08:38
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Да мне тоже erlang очень нравится. Но он не рулит, а просто инструмент.

Да любой современный язык — по умолчанию не переменная (var), а val, которой не изменить значение после присваивания. Надеюсь до чистой Java такое вскоре тоже дойдет, это как раз то, что можно исправить, хоть и не полностью. Даже такой капец, как JavaScript — там именно с фичами то не так и плохо, там в другом проблема.
Re[2]: Чем плох Паскаль?
От: AlexRK  
Дата: 14.06.19 09:05
Оценка:
Здравствуйте, Александр Кузнецов, Вы писали:

АК>Я вам открою страшную тайну: за исключением JavaScript, все "современные" языки программирования (по крайней мере из числа более-менее использующихся на практике) практически не имеют неоднозначностей в синтаксисе. По крайней мере на том уровне, на котором учат в школё/ВУЗе.


Я вам открою страшную тайну: все "современные" языки программирования (по крайней мере из числа более-менее использующихся на практике) имеют немало неоднозначностей в синтаксисе. А в Ц++ этих неоднозначностей столько, что даже парсинг кода не может быть выполнен без семантического анализа.
Re[2]: Чем плох Паскаль?
От: alpha21264 СССР  
Дата: 14.06.19 09:10
Оценка:
Здравствуйте, itmanager85, Вы писали:

I>зачем обучать мёртвому языку ?


В инязе обучение английскому начинают с латыни. Ну это так, в качестве примера.
http://s19.rimg.info/0871fde0709f1bd37b3b012eb22a4583.gif
Течёт вода Кубань-реки куда велят большевики.
Re[3]: Чем плох Паскаль?
От: Александр Кузнецов Россия  
Дата: 14.06.19 09:16
Оценка:
Здравствуйте, AlexRK, Вы писали:

АК>>Я вам открою страшную тайну: за исключением JavaScript, все "современные" языки программирования (по крайней мере из числа более-менее использующихся на практике) практически не имеют неоднозначностей в синтаксисе. По крайней мере на том уровне, на котором учат в школё/ВУЗе.


ARK>Я вам открою страшную тайну: все "современные" языки программирования (по крайней мере из числа более-менее использующихся на практике) имеют немало неоднозначностей в синтаксисе. А в Ц++ этих неоднозначностей столько, что даже парсинг кода не может быть выполнен без семантического анализа.


Если честно, то на вскидку не могу припомнить ни одной. Либо мозг уже давно привык эти неоднозначности вполне себе однозначно разбирать, либо в командах, в которых мне приходилось работать, всегда слишком строгое соблюдение coding style было.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Re[3]: Чем плох Паскаль?
От: Александр Кузнецов Россия  
Дата: 14.06.19 09:26
Оценка:
Здравствуйте, Pzz, Вы писали:

C>>В современном варианте было бы лучше что-то типа Питона с графической средой. Или как вариант: https://www.apple.com/swift/playgrounds/ — лучшее, что я вообще видел для детей.


Pzz>Мне кажется, использование в качестве первого языка, языка с динамической типизацией, уродует головной мозг человека навсегда.


Не навсегда, лечится, но да, процесс восстановления пациента обычно очень долгий и запущенный.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Re[4]: Чем плох Паскаль?
От: AlexRK  
Дата: 14.06.19 09:54
Оценка:
Здравствуйте, Александр Кузнецов, Вы писали:

АК>>>Я вам открою страшную тайну: за исключением JavaScript, все "современные" языки программирования (по крайней мере из числа более-менее использующихся на практике) практически не имеют неоднозначностей в синтаксисе. По крайней мере на том уровне, на котором учат в школё/ВУЗе.


ARK>>Я вам открою страшную тайну: все "современные" языки программирования (по крайней мере из числа более-менее использующихся на практике) имеют немало неоднозначностей в синтаксисе. А в Ц++ этих неоднозначностей столько, что даже парсинг кода не может быть выполнен без семантического анализа.


АК>Если честно, то на вскидку не могу припомнить ни одной. Либо мозг уже давно привык эти неоднозначности вполне себе однозначно разбирать, либо в командах, в которых мне приходилось работать, всегда слишком строгое соблюдение coding style было.


Ну вот по сишарпу кое-что: http://ecsharp.net/lllpg/8-managing-ambiguity.html
И в стандарте есть целый раздел «Grammar ambiguites».
Как распарсить «a.b.c.d.e;»? Без семантической информации — никак.

В Ц++ хотя бы "a();" — что это? Тип? Функция?

С парсингом знаков "<", ">" — в почти всех современных языках ад и израиль.
Re[5]: Чем плох Паскаль?
От: Александр Кузнецов Россия  
Дата: 14.06.19 10:28
Оценка:
Здравствуйте, AlexRK, Вы писали:

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


АК>>>>Я вам открою страшную тайну: за исключением JavaScript, все "современные" языки программирования (по крайней мере из числа более-менее использующихся на практике) практически не имеют неоднозначностей в синтаксисе. По крайней мере на том уровне, на котором учат в школё/ВУЗе.


ARK>>>Я вам открою страшную тайну: все "современные" языки программирования (по крайней мере из числа более-менее использующихся на практике) имеют немало неоднозначностей в синтаксисе. А в Ц++ этих неоднозначностей столько, что даже парсинг кода не может быть выполнен без семантического анализа.


АК>>Если честно, то на вскидку не могу припомнить ни одной. Либо мозг уже давно привык эти неоднозначности вполне себе однозначно разбирать, либо в командах, в которых мне приходилось работать, всегда слишком строгое соблюдение coding style было.


ARK>Ну вот по сишарпу кое-что: http://ecsharp.net/lllpg/8-managing-ambiguity.html


Примеры взяты из ссылок выше:
1. for (i = j + 1; -i > k; ++i) — сначала берём тяжёлую дубину и ломаем ей руки автора кода. Потом собираем руки обратно, выпрямляем, объясняем, в чём именно автор не прав, и даём написать ещё пару строчек. При необходимости повторять до полного просветления автора. В особо упёртых случаях применяется метод из п. 2.

2.
class A { public virtual void F(Foo x) {...} }
class B : A {
public override void F(Foo x) {...} // first
public void F(Bar x) {...} // second
}
Берём раскалённый паяльник и методом терморектального криптоанализа выясняем, что именно автор хотел сказать данной синтаксической конструкцией. Скорее всего, сказать он не хотел ничего, так как думал он в процессе её создания тем самым местом, в которое сейчас помещён паяльник. Но если вдруг объяснение автора является единственным решением, возможным при текущей архитектуре кода, паяльник (существенно большего размера) помещается в то место, которым думал, с позволения сказать, архитектор данной системы. Одного сеанса обычно хватает. Если нет, то лучше сразу в морг.

Остальное в основном в том же духе.

ARK>И в стандарте есть целый раздел «Grammar ambiguites».

ARK>Как распарсить «a.b.c.d.e;»? Без семантической информации — никак.

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

Только у топикстартера всё-таки про обучение, а не про специфику с узкой областью применения. Причём про самое начало обучения, а не про написание компиляторов, или нюансы передачи времени с .NET на iOS.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Re: Чем плох Паскаль?
От: qwertyuiop Российская Империя  
Дата: 14.06.19 11:29
Оценка:
Здравствуйте, Cicero, Вы писали:

C>Обычно аргументов нет.


Если ты это уже знаешь, зачем вообще создаешь тему?
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Re[5]: Чем плох Паскаль?
От: AlexRK  
Дата: 14.06.19 11:32
Оценка:
Здравствуйте, netch80, Вы писали:

N>в if, else, while нужно строить блок вокруг нескольких предложений, а в repeat-until — нет


В Ц/Ц++ то же самое — в do надо обязательно ставить {}, а в других местах — нет.

N>в конце main надо ставить точку после end, а у остальных — точку с запятой


Дааа... в других-то языках все иначе, да?

The main function has several special properties:
1) It cannot be used anywhere in the program
a) in particular, it cannot be called recursively
b) its address cannot be taken
2) It cannot be predefined and cannot be overloaded: effectively, the name main in the global namespace is reserved for functions (although it can be used to name classes, namespaces, enumerations, and any entity in a non-global namespace, except that a function called "main" cannot be declared with C language linkage in any namespace (since C++17))
3) It cannot be defined as deleted or declared with C language linkage (since C++17), inline, static, or constexpr
4) The body of the main function does not need to contain the return statement: if control reaches the end of main without encountering a return statement, the effect is that of executing return 0;.
5) Execution of the return (or the implicit return upon reaching the end of main) is equivalent to first leaving the function normally (which destroys the objects with automatic storage duration) and then calling std::exit with the same argument as the argument of the return. (std::exit then destroys static objects and terminates the program)
6) (since C++14) The return type of the main function cannot be deduced (auto main() {... is not allowed)


N>что var идёт перед основным телом


Просто другой подход.

N>что and и or почему-то приоритетнее сравнений


А почему должно быть наоборот?
Re[2]: Чем плох Паскаль?
От: qwertyuiop Российская Империя  
Дата: 14.06.19 11:41
Оценка:
Здравствуйте, netch80, Вы писали:

N>Синтаксис цикла — for i := 1 to 10, например. Сначала ":=" несловесной лексемой, затем почему-то "to" — словесной. А назад — downto. Кстати, если я хочу шаг 2?


Почему-то апологеты считают строгость положительным качеством. Однако выучившись на Паскале, ученики и на Си будут писать в паскалеподобном стиле, хотя там шаг может быть любым, а переменная цикла может быть любого типа или вообще отсутствовать. Главное, что там есть три оператора: инициализация, оператор, проверяющий условие окончания цикла и оператор выполняемый в конце. Вот это — действительно строгость, ничего лишнего! Но зато есть гибкость.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Re[6]: Чем плох Паскаль?
От: Пацак Россия  
Дата: 14.06.19 11:52
Оценка:
Здравствуйте, elmal, Вы писали:

E>Да любой современный язык — по умолчанию не переменная (var), а val, которой не изменить значение после присваивания. Надеюсь до чистой Java такое вскоре тоже дойдет, это как раз то, что можно исправить, хоть и не полностью.


А стоит ли игра свеч? Иммутабильности объектам использование val по умолчанию не добавит, а менять синтаксис только ради того, чтобы нельзя было повторно переприсвоить локальную переменную... Ну чо-та как-то немного из пушки по воробьям, по-моему, не?
Ку...
Re[7]: Чем плох Паскаль?
От: elmal  
Дата: 14.06.19 12:39
Оценка:
Здравствуйте, Пацак, Вы писали:

П>А стоит ли игра свеч? Иммутабильности объектам использование val по умолчанию не добавит, а менять синтаксис только ради того, чтобы нельзя было повторно переприсвоить локальную переменную... Ну чо-та как-то немного из пушки по воробьям, по-моему, не?

Ну, это не изменение синтаксиса, это его добавление. А вообще, я надеюсь что с появлением Data Types будет заодно и нормальная иммутабельность объектов.
Re[5]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 12:51
Оценка:
Здравствуйте, pagid, Вы писали:

N>>Из этого не следует необходимость обучения мёртвому языку.

N>>Из живых на эту роль отлично подходит, например, Go (ближайший по духу), Java, C#, Python.
P>Тоже можно. Но в C# и Java больше условностей совершенно излишних — не забыть импортировать пакеты, написать хотя бы один класс, ни к чему это школьникам.

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

N>>Для системного уровня — C.

P>Зачем системный уровень школьникам

В контексте не только школы, но и вузы.

N>>Во-первых, должна быть. Учат чему-то полезному, и конкретный язык здесь, хоть и не первоочередная составляющая, но важная. А если ещё при обучении человек сразу включается в реальную работу и видит полезный выхлоп от своей работы — то это ещё больше работает на качество обучения.

P>Математике и литературе в школе тоже учат чтобы можно было сразу включиться в реальную работу?

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

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

P>Что там переучиваться если разговор про первоначальное обучение там что переучиваться на другой язык, что доучиваться на том же до профессионального уровня трудозатраты примерно те же. А при этом представление о том, что языки бывают разные вредным не будет.

Отлично, с таким подходом надо учить 2-3 языка, но все три актуальных и полезных, а не древние окаменелости. И лучше, если одним из них будет что-то андедное актуальное вроде LISP.
Отредактировано 14.06.2019 12:52 netch80 . Предыдущая версия .
Re: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 14.06.19 12:51
Оценка:
Здравствуйте, Cicero, Вы писали:

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

C>Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!
Сейчас модно визуальное программирование, что бы ярко, модно, молодёжно

https://www.youtube.com/watch?v=6GpdoJXpo2U
Отредактировано 14.06.2019 12:52 kov_serg . Предыдущая версия .
Re[5]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 13:08
Оценка:
Здравствуйте, kov_serg, Вы писали:

N>>Из живых на эту роль отлично подходит, например, Go (ближайший по духу), Java, C#, Python. Для системного уровня — C.

_>Есть же Perl!

Как же я мог забыть!

всё, вопрос закрыт.

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

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

+100500. Но — всё равно живой язык полезнее.
Re[3]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 13:10
Оценка:
Здравствуйте, qwertyuiop, Вы писали:

N>>Синтаксис цикла — for i := 1 to 10, например. Сначала ":=" несловесной лексемой, затем почему-то "to" — словесной. А назад — downto. Кстати, если я хочу шаг 2?


Q>Почему-то апологеты считают строгость положительным качеством. Однако выучившись на Паскале, ученики и на Си будут писать в паскалеподобном стиле, хотя там шаг может быть любым, а переменная цикла может быть любого типа или вообще отсутствовать. Главное, что там есть три оператора: инициализация, оператор, проверяющий условие окончания цикла и оператор выполняемый в конце. Вот это — действительно строгость, ничего лишнего! Но зато есть гибкость.


Ну для обучения ещё неизвестно, что лучше.
Циклы в сишном стиле — тут надо зазубрить идиомы, что переменная итератора всегда одна и та же (а иначе будет долго втыкать, что не так в каком-нибудь for (i = 0; ii < 100; ++i)), или, если это нарушается, нужно смотреть внимательнее, что происходит. В синтаксисе foreach-стиля это само получается.
Re[9]: Чем плох Паскаль?
От: AlexRK  
Дата: 14.06.19 13:11
Оценка:
Здравствуйте, netch80, Вы писали:

N>Нет, не образует.

N>не скомпилируется.

Да, точно. Забавно. Но, скажем, в сишарпе {} после do обязательны: https://ideone.com/UcHEPr
Да и в жабе тоже. Так что не паскалем единым.

N>Что, много кто пытается вызвать main рекурсивно? Что-то ни разу не видел.


Еще раз: main — особая функция. Особой функции — особый синтаксис.

Ну и «не видел» — аргумент тоже так себе.

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

N>Боюсь представить себе, как выглядит твой код и как на это ругаются коллеги.
N>Рекомендовать всем такое, увы, не могу.

Не бойся. Отлично выглядит и однозначно читается. По себе всех не суди.
Re[10]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 13:19
Оценка:
Здравствуйте, AlexRK, Вы писали:

N>>Нет, не образует.

N>>не скомпилируется.
ARK>Да, точно. Забавно. Но, скажем, в сишарпе {} после do обязательны: https://ideone.com/UcHEPr
ARK>Да и в жабе тоже. Так что не паскалем единым.

Ну я вообще считаю, что {} надо делать обязательными везде. Речь-то шла о существующем.

N>>Что, много кто пытается вызвать main рекурсивно? Что-то ни разу не видел.

ARK>Еще раз: main — особая функция. Особой функции — особый синтаксис.

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

ARK>Ну и «не видел» — аргумент тоже так себе.


Аргумент очень даже осмысленный. Да, у меня не было 1000 студентов, как у Кузнецова. Но несколько — были. И я помню, что им не было дела до того, что такого особенного в main — но было до того, что надо про эту точку особо помнить.

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

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

N>>Боюсь представить себе, как выглядит твой код и как на это ругаются коллеги.
N>>Рекомендовать всем такое, увы, не могу.
ARK>Не бойся. Отлично выглядит и однозначно читается. По себе всех не суди.

По себе и не сужу, и всех не сужу, пытаюсь оценить конкретно тебя и этот код. Пример можно?
А ассоциативность ты тоже явно помечаешь? a+b+c нельзя, можно только (a+b)+c?
Re[2]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 13:26
Оценка:
Здравствуйте, borga, Вы писали:

B>Читая ответы коллег у меня возникает странное чувство непонимания.


B>Если это касается школы: вы реально считаете что там вот это все о чем Вы спорите важно?

B>Там ИМХО все изучается на элементарном уровне.
B>Какие указатели? Вы о чем?

Да, там другие грабли, и я их описал
Автор: netch80
Дата: 13.06.19
.

B>Что же касается более продвинутого уровня.

B>Вам вот реально важно begin/end или {}?

Да. Потому что
1) лучше, когда синтаксические средства группировки заметно выделяются формой, чем сливаются с другими словами и идентификаторы.
2) например, есть штатные средства перейти на противоположную скобку (любого вида) в каком-нибудь vim, но с begin/end это становится в разы сложнее. Учить редакторы фолдить тоже усложнение.
Re[11]: Чем плох Паскаль?
От: AlexRK  
Дата: 14.06.19 15:09
Оценка:
Здравствуйте, netch80, Вы писали:

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


Существующая ситуация состоит в том, что блок repeat-until не является уникальным для паскаля.

N>Много функций особых. Есть вложенные. Есть всякие interrupt handlers или обработчики сигналов.

N>Есть вызываемые при старте и стопе программы. Есть функции тредов.

По-моему, все эти функции с точки зрения языка особенными не являются. Например, обработчик прерывания — чем он особенный?

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


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

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

N>Хотя конкретный компилятор может сделать из неё _MAINQQ$$, если ему так нравится

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

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


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

N>По себе и не сужу, и всех не сужу, пытаюсь оценить конкретно тебя и этот код. Пример можно?


if ((a > 3) && (b == 4))

N>А ассоциативность ты тоже явно помечаешь? a+b+c нельзя, можно только (a+b)+c?


Ассоциативность во всех случаях, с какими я имел дело, всегда слева направо. Поэтому не помечаю. Но если бы пришлось писать код, где ассоциативность иная (всякие там сложения вещественных чисел в чувствительных к этому алгоритмах) — то обязательно бы пометил.
Re[3]: Чем плох Паскаль?
От: Джеффри  
Дата: 14.06.19 15:38
Оценка:
Здравствуйте, ksandro, Вы писали:

K>Чувствую себя старым... Народ уже забыл что такое Delphi...

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

ТС предлагает использовать Паскаль 5.5 / Турбо Паскаль для обучения — так что мой комментарий относится к этой версии.

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

А так из реальных недостатков — он вроде платный был раньше? не помню была раньше какая-то бесплатная education / developer версия?
Re[6]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 14.06.19 16:37
Оценка:
Здравствуйте, 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 клиента, не к ночи будь сказано).


Какие в школе расширенные случаи? Даже сортировка... написали один раз сортировку пузырьком, и достаточно. Больше она нигде в школьной программе не нужна, по крайней мере в той школьной программе, которой меня учили. А школьная программа, по которой меня учили, была слишком сложная и так, оттуда бы ещё половину выкинуть.
Re[3]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 14.06.19 16:41
Оценка:
Здравствуйте, netch80, Вы писали:

N>Да. Потому что

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

Ну кого, нафиг, фолдить? Школьная программа должна влезать на тетрадный лист в клетку, 40 строк. Ну, в крайнем случае, два экрана — 50 строк. В ней нет смысла ничего фолдить. Это школа, а не курсы молодого бойца.
Re[3]: Чем плох Паскаль?
От: Джеффри  
Дата: 14.06.19 16:54
Оценка:
Здравствуйте, AlexRK, Вы писали:

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


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

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

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

ARK>За этим надо идти в ПТУ, а не в ВУЗ.

Зачем сразу ПТУ? Если мы, например, говорим о школе или не-программерской специальности в ВУЗе, вопрос — нужно ли учить таким людям основы программирования? И если нужно (я склоняюсь к этому), то должны ли они учить их на неком абстрактном языке, который позволит получить им правильную алгоритмическую базу и усвоить правильные академические концепции (но которые скорей всего лягут мертвым грузом сразу)? Или учить в облегченном варианте, но с прицелом на то, чтобы им было их легче применить на практических задачах?
Re: Чем плох Паскаль?
От: okon  
Дата: 14.06.19 17:18
Оценка:
C>Почему:
C>Говоря двумя словами: потому что в Паскале минимум неоднозначности синтаксиса.

Паскаль не плох, его не любят т.к. он не был программистом, и мало знают так как умер давно.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[6]: Чем плох Паскаль?
От: Слава  
Дата: 14.06.19 17:44
Оценка:
Здравствуйте, Александр Кузнецов, Вы писали:

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


Проблема в том, что не приходят. К строителям ещё могут придти, к медикам. К электрикам. А к программистам — нет.
Re[7]: Чем плох Паскаль?
От: Александр Кузнецов Россия  
Дата: 14.06.19 17:47
Оценка:
Здравствуйте, Слава, Вы писали:

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


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


Ну так это проблема не языка, а отсутствия процессов. Конкретно процесса code review. То, что в Паскале нельзя написать конкретно данную конструкцию не говорит о том, что в нём нельзя написать 100 других.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Re[7]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 14.06.19 17:54
Оценка:
Здравствуйте, AlexRK, Вы писали:

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

ARK>А в Го массивы, хеши, каналы — это не магическое, не? Синтаксис не странный?
Ну так я и не предлагаю Го как язык для обучения.
Sapienti sat!
Re[8]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 14.06.19 18:00
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

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

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

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


Да, и массивы выкинуть.
Re[5]: Чем плох Паскаль?
От: Александр Кузнецов Россия  
Дата: 14.06.19 18:01
Оценка:
Здравствуйте, netch80, Вы писали:

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


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


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

N>вот честно говоря, написать сложную конструкцию серьёзнее, чем a (*b)()[3]; без бутылки будет трудновато. Так что C/C++ и в этом смысле ой.

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

Возможно, есть ещё какие-то варианты, но я только с этими тремя сталкивался.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Re[7]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 14.06.19 18:21
Оценка:
Здравствуйте, 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-указатель (хоть он так и не назывался).

Ну вот потому С как раз очень помогает понять указатели, в отличие от Паскаля. С точки зрения промышленного программирования с указателями в С — полная катастрофа с безопасностью, но для обучения как раз идеально.
Sapienti sat!
Re[4]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 15.06.19 04:10
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

N>>Да. Потому что

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

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


В среднем школьном возрасте уже пора заниматься чем-то реальным. В старшем и вузе — тем более. Обучение программированию не означает необходимости гонять гномиков по экрану и считать простые числа. А понимание того, что твои 30 строчек помогли проекту на пару миллионов строк, морально подстёгивает профессиональный рост лучше, чем тупые отметки "отлично".
Re[12]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 15.06.19 04:48
Оценка:
Здравствуйте, 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; ?
Re[13]: Чем плох Паскаль?
От: AlexRK  
Дата: 15.06.19 08:07
Оценка:
Здравствуйте, netch80, Вы писали:

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

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

С первой попытки. Просто на Ц много лет не писал, да и do не использовал — думал, что там как в шарпе.

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

N>Ну вот и дают, например, простановкой атрибутов (ранее — спец. ключевыми словами).

Ну раз дают, то к чему вопрос был.

N>А зачем при этом менять метод парсинга?


Метод парсинга не меняется. Точка означает завершение модуля.

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

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

Э... ну и? Слово program он тоже способен написать и увидеть, чем оно хуже?

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

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

Странный список, считать хаскель языком для обучения? Ну и бред.

Ну и да — повторял кто что или не повторял — тоже не особо показатель. Куча языков слепо повторяла и повторяет вредные или убогие концепции (см. ошибка на миллиард долларов или С-like switch с провалами или синтаксическим мусором).

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


x = a + (b * c);

Сразу беглым взглядом четко видно структуру выражения.

Кстати, многие языки и вовсе не имеют приоритета операторов — smalltalk, prolog, lisp, pony, наверняка еще кучу забыл.
Re[8]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 15.06.19 13:41
Оценка:
Здравствуйте, netch80, Вы писали:

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


N>Это ваша религия говорит?


Да

N>И она хоть как-то это пытается обосновать?

N>Чем плохо иметь и использовать тип данных "хранилище ключ-значение"?

Иметь и использовать типы данных — это прекрасно. Не прекрасно засирать этим голову школьникам (и, кстати, школьницам) в обязательном порядке.

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


Да. Не упираться в суммы чётных элементов, потому что это массивы, а массивы — тоже лишнее. Сумму чётных элементов последователности, или предел последовательности, или что-то такое. Поиск корня уравнения делением пополам, или ещё что-то типа такого (после того, как это в математике изучили). Я помню у нас была задача "нарисуйте движение планет солнечной системы, без масштаба". Ну то есть нужно нарисовать несколько кружочков (или точек), движущихся по окружностям вокруг центра. Отдельные бонусы за Луну и кольца Сатурна. Этого достаточно. Все желающие узнать, что такое хештаблица, и чем отличается криптографический хеш от используемого в хештаблице, приглашаются на факультативные занятия информатикой.
Re[6]: Чем плох Паскаль?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 15.06.19 16:42
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:



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


Так программирование нужно как раз для решения множества задач. По математике, физике, биологии с химией. Это инструмент наравне с математикой.
Да для большинства задач хватит и MATLAB. Вот с него для тоже стоит начинать, тем более можно использовать внешние инструменты https://ru.wikipedia.org/wiki/MATLAB#Внешние_интерфейсы
и солнце б утром не вставало, когда бы не было меня
Re[7]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 15.06.19 18:19
Оценка:
Здравствуйте, Serginio1, Вы писали:

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




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


S> Так программирование нужно как раз для решения множества задач.


По математике, может быть и да. А вот будущим билолгам с химиками хочется не вот этой твоей нуднятины с обработкой результатов, а интересного. Жуков там на иголки насаживать, бомбы делать, вот это всё. Обработку им сувать сейчас — отобьешь интерес навсегда.
Отредактировано 15.06.2019 18:33 Sharowarsheg . Предыдущая версия . Еще …
Отредактировано 15.06.2019 18:19 Sharowarsheg . Предыдущая версия .
Re[6]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 15.06.19 18:34
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ерунда полнейшая.

C>Ну и где больше шума?
Естественно где явно по месту определяют тип переменной.
  Например
llvm::Value *
ItaniumCXXABI::EmitMemberPointerComparison(CodeGenFunction &CGF,
                                           llvm::Value *L,
                                           llvm::Value *R,
                                           const MemberPointerType *MPT,
                                           bool Inequality) {
  CGBuilderTy &Builder = CGF.Builder;

  llvm::ICmpInst::Predicate Eq;
  llvm::Instruction::BinaryOps And, Or;
  if (Inequality) {
    Eq = llvm::ICmpInst::ICMP_NE;
    And = llvm::Instruction::Or;
    Or = llvm::Instruction::And;
  } else {
    Eq = llvm::ICmpInst::ICMP_EQ;
    And = llvm::Instruction::And;
    Or = llvm::Instruction::Or;
  }

  // Member data pointers are easy because there's a unique null
  // value, so it just comes down to bitwise equality.
  if (MPT->isMemberDataPointer())
    return Builder.CreateICmp(Eq, L, R);

  // For member function pointers, the tautologies are more complex.
  // The Itanium tautology is:
  //   (L == R) <==> (L.ptr == R.ptr && (L.ptr == 0 || L.adj == R.adj))
  // The ARM tautology is:
  //   (L == R) <==> (L.ptr == R.ptr &&
  //                  (L.adj == R.adj ||
  //                   (L.ptr == 0 && ((L.adj|R.adj) & 1) == 0)))
  // The inequality tautologies have exactly the same structure, except
  // applying De Morgan's laws.

  llvm::Value *LPtr = Builder.CreateExtractValue(L, 0, "lhs.memptr.ptr");
  llvm::Value *RPtr = Builder.CreateExtractValue(R, 0, "rhs.memptr.ptr");

  // This condition tests whether L.ptr == R.ptr.  This must always be
  // true for equality to hold.
  llvm::Value *PtrEq = Builder.CreateICmp(Eq, LPtr, RPtr, "cmp.ptr");

  // This condition, together with the assumption that L.ptr == R.ptr,
  // tests whether the pointers are both null.  ARM imposes an extra
  // condition.
  llvm::Value *Zero = llvm::Constant::getNullValue(LPtr->getType());
  llvm::Value *EqZero = Builder.CreateICmp(Eq, LPtr, Zero, "cmp.ptr.null");

  // This condition tests whether L.adj == R.adj.  If this isn't
  // true, the pointers are unequal unless they're both null.
  llvm::Value *LAdj = Builder.CreateExtractValue(L, 1, "lhs.memptr.adj");
  llvm::Value *RAdj = Builder.CreateExtractValue(R, 1, "rhs.memptr.adj");
  llvm::Value *AdjEq = Builder.CreateICmp(Eq, LAdj, RAdj, "cmp.adj");

  // Null member function pointers on ARM clear the low bit of Adj,
  // so the zero condition has to check that neither low bit is set.
  if (UseARMMethodPtrABI) {
    llvm::Value *One = llvm::ConstantInt::get(LPtr->getType(), 1);

    // Compute (l.adj | r.adj) & 1 and test it against zero.
    llvm::Value *OrAdj = Builder.CreateOr(LAdj, RAdj, "or.adj");
    llvm::Value *OrAdjAnd1 = Builder.CreateAnd(OrAdj, One);
    llvm::Value *OrAdjAnd1EqZero = Builder.CreateICmp(Eq, OrAdjAnd1, Zero,
                                                      "cmp.or.adj");
    EqZero = Builder.CreateBinOp(And, EqZero, OrAdjAnd1EqZero);
  }

  // Tie together all our conditions.
  llvm::Value *Result = Builder.CreateBinOp(Or, EqZero, AdjEq);
  Result = Builder.CreateBinOp(And, PtrEq, Result,
                               Inequality ? "memptr.ne" : "memptr.eq");
  return Result;
}

И вынесенные объявления.
llvm::Value *
ItaniumCXXABI::EmitMemberPointerComparison(CodeGenFunction &CGF,
                                           llvm::Value *L,
                                           llvm::Value *R,
                                           const MemberPointerType *MPT,
                                           bool Inequality) {
  CGBuilderTy &Builder = CGF.Builder;
  llvm::ICmpInst::Predicate Eq;
  llvm::Instruction::BinaryOps And, Or;
  llvm::Value *LPtr, *RPtr, *PtrEq, *Zero, *EqZero *LAdj, *RAdj, 
    *AdjEq, *One, *OrAdj, *OrAdjAnd1, *OrAdjAnd1EqZero, *Result;

  if (Inequality) {
    Eq = llvm::ICmpInst::ICMP_NE;
    And = llvm::Instruction::Or;
    Or = llvm::Instruction::And;
  } else {
    Eq = llvm::ICmpInst::ICMP_EQ;
    And = llvm::Instruction::And;
    Or = llvm::Instruction::Or;
  }

  // Member data pointers are easy because there's a unique null
  // value, so it just comes down to bitwise equality.
  if (MPT->isMemberDataPointer())
    return Builder.CreateICmp(Eq, L, R);


  // For member function pointers, the tautologies are more complex.
  // The Itanium tautology is:
  //   (L == R) <==> (L.ptr == R.ptr && (L.ptr == 0 || L.adj == R.adj))
  // The ARM tautology is:
  //   (L == R) <==> (L.ptr == R.ptr &&
  //                  (L.adj == R.adj ||
  //                   (L.ptr == 0 && ((L.adj|R.adj) & 1) == 0)))
  // The inequality tautologies have exactly the same structure, except
  // applying De Morgan's laws.

  LPtr = Builder.CreateExtractValue(L, 0, "lhs.memptr.ptr");
  RPtr = Builder.CreateExtractValue(R, 0, "rhs.memptr.ptr");

  // This condition tests whether L.ptr == R.ptr.  This must always be
  // true for equality to hold.
  PtrEq = Builder.CreateICmp(Eq, LPtr, RPtr, "cmp.ptr");

  // This condition, together with the assumption that L.ptr == R.ptr,
  // tests whether the pointers are both null.  ARM imposes an extra
  // condition.
  Zero = llvm::Constant::getNullValue(LPtr->getType());
  EqZero = Builder.CreateICmp(Eq, LPtr, Zero, "cmp.ptr.null");

  // This condition tests whether L.adj == R.adj.  If this isn't
  // true, the pointers are unequal unless they're both null.
  LAdj = Builder.CreateExtractValue(L, 1, "lhs.memptr.adj");
  RAdj = Builder.CreateExtractValue(R, 1, "rhs.memptr.adj");
  AdjEq = Builder.CreateICmp(Eq, LAdj, RAdj, "cmp.adj");

  // Null member function pointers on ARM clear the low bit of Adj,
  // so the zero condition has to check that neither low bit is set.
  if (UseARMMethodPtrABI) {
    One = llvm::ConstantInt::get(LPtr->getType(), 1);

    // Compute (l.adj | r.adj) & 1 and test it against zero.
    OrAdj = Builder.CreateOr(LAdj, RAdj, "or.adj");
    OrAdjAnd1 = Builder.CreateAnd(OrAdj, One);
    OrAdjAnd1EqZero = Builder.CreateICmp(Eq, OrAdjAnd1, Zero,
                                                      "cmp.or.adj");
    EqZero = Builder.CreateBinOp(And, EqZero, OrAdjAnd1EqZero);
  }

  // Tie together all our conditions.
  Result = Builder.CreateBinOp(Or, EqZero, AdjEq);
  Result = Builder.CreateBinOp(And, PtrEq, Result,
                               Inequality ? "memptr.ne" : "memptr.eq");
  return Result;
}
Если компилятор сам умеет выводить тип переменной и место где она впервые появилась то достаточно указать что такие переменные будут. Объявления переменных нужны только что бы отлавливать опечатки в названиях переменных.
Re[3]: Чем плох Паскаль?
От: Michael7 Россия  
Дата: 15.06.19 19:40
Оценка:
Здравствуйте, Pzz, Вы писали:


Pzz>Я б добавил к этому отсутствие возможности вернуть из функции указатель на функцию, при том что сами по себе такие указатели в языке есть.


Это только в оригинальном паскале нельзя, в турбо-паскале (и дельфи) уже давно есть тип-функция, который ничто не мешает возвращать.
Вообще довольно много претензий к паскалю были исправлены в итоге в дельфи.
Re[2]: Чем плох Паскаль?
От: Michael7 Россия  
Дата: 15.06.19 19:47
Оценка:
Здравствуйте, itmanager85, Вы писали:

I>зачем обучать мёртвому языку ?


Все же, если иметь ввиду не классический паскаль, то не такой он и мертвый.
Даже новые версии Delphi регулярно выходят. Есть и FreePascal с Lazarus. На них вполне можно и пишут реальные вещи. В теме статьи Lazarus на вики даже приведены примеры реальных проектов.

I>намного более актуальны c/c++ | Java | C# | PHP | MySql — после них хоть к станку (особенно если JS/JQuery добавить)


У меня ощущение, что в качестве первого языка они все же не подходят. Хотя сейчас наверное ни один язык вообще не подходит. Какое-то программирование нынче стало даже не подберу точного слова, но в общем сильно не такое, как даже еще 20 лет назад.
Re[7]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 15.06.19 20:48
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>И вынесенные объявления.

Уродство. Чистейшее уродство из-за повреждения моска Паскалем.

Я уж не говорю, что все определения нынче легко можно заменить на "auto". В данном случае явный тип переменной по месту служит дополнительной документацией (чтобы не нужно было IDE напрягать), тогда как в варианте "мессиво в начале функции" он полностью бесполезен.
Sapienti sat!
Re[9]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 15.06.19 21:20
Оценка:
Здравствуйте, Serginio1, Вы писали:

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



S>>По математике, может быть и да. А вот будущим билолгам с химиками хочется не вот этой твоей нуднятины с обработкой результатов, а интересного. Жуков там на иголки насаживать, бомбы делать, вот это всё. Обработку им сувать сейчас — отобьешь интерес навсегда.


S> Ну в итоге то вся работа будет связана именно с обработкой данных. И нужно не только жуков на иголки насаживать.


Ну, во-первых, не вся. Например, органический синтез требует рук, определенного мышления, и часто бумаги с карандашом. Компьютером эту часть пока не научились заменять, и не научатся ближайшее время. Биология тоже, или какая-нибудь геология, требует действий руками, которые компьютером не заменяются. Во-вторых,химикам, скажем, в обработке данных самый ходовой рабочий инструмент — эксель, и на многих специализациях никакие языки программирования не нужны вообще. Я знаю, плавал, причём довольно глубоко. А в школьной химии уж точно обработка данных вся — посчитать среднее из трёх значений, и то не всегда.

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


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

S> А вот зная постановку задачи и её решение все становится значительно проще.


Это хорошая философия, но для института, и то не всегда. В школе нет никаких задач в естественных предметах, где программирование как-то участвует или в постановке задач, или в решении.
Re[10]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 15.06.19 21:23
Оценка:
Здравствуйте, Ops, Вы писали:

S>>Иметь и использовать типы данных — это прекрасно. Не прекрасно засирать этим голову школьникам (и, кстати, школьницам) в обязательном порядке.


Ops>Это куда проще многих других школьных концепций. Может производные тоже выкинуть из школьной программы?


Во-первых, выкинуть. Во-вторых, дело не только в сложности и простоте, но и в количестве. Например, язык орков гораздо проще английского или немецкого, и, в отличие от производных, может пригодиться, когда смотришь Lord of the rings. Это же не причина включить язык орков в школьную программу?
Re[3]: Чем плох Паскаль?
От: borga  
Дата: 15.06.19 21:29
Оценка:
Здравствуйте, netch80, Вы писали:

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


B>>Читая ответы коллег у меня возникает странное чувство непонимания.


B>>Если это касается школы: вы реально считаете что там вот это все о чем Вы спорите важно?

B>>Там ИМХО все изучается на элементарном уровне.
B>>Какие указатели? Вы о чем?

N>Да, там другие грабли, и я их описал
Автор: netch80
Дата: 13.06.19
.


B>>Что же касается более продвинутого уровня.

B>>Вам вот реально важно begin/end или {}?

N>Да. Потому что

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

Это все глупости я даже не буду опровергать.
Человек вполне конкретно расписал вот тут
Автор: scf
Дата: 16.06.19
: вникайте до просветления!
Re[2]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 15.06.19 21:29
Оценка:
Здравствуйте, scf, Вы писали:

scf>НО — для начального обучениния избыток парадигм вреден. К примеру, вот что входило в мою школьную программу:

scf>- понятие алгоритма
scf>- операторы, переменные, типы, условия, циклы
scf>- процедуры, функции
scf>- структуры данных: массивы, строки, списки, деревья
scf>- алгоритмы: поиск элементов в масивах, обход списков, обход деревьев, двоичный поиск, решение уравнений методом деления пополам
scf>- ascii графика (типа распечатать таблицу умножения)
scf>- цветная графика — нарисовать пейзаж, анимация, графики, графики трехмерных функций по алгоритму художника

scf>Этого списка достаточно, чтобы загрузить школьников до 11 класса включительно. Надеюсь, никто не будет спорить, что а) всё перечисленное нужно


Я буду. Списки выбросить вместе с указателями. Можно и массивы тоже выбросить. Заодно и графики трёхмерных функций, всё равно стереометрия где-то в самом конце последнего класса, если я правильно помню, а к этому времени все уже определятся, будут они поступать на информатику или нет. Те, кто будут, тем факультатив, а остальные пусть хоть стереометрию осилят.
Re[5]: Чем плох Паскаль?
От: Marty Пират  
Дата: 15.06.19 21:31
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>>>Почему некоторые люди считают что объявление переменных по месту это хорошо? Чем плохо заранее объявить что понадобиться, а не равномерно размызвать безполезное гавно по коду.

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

Я бы не сказал, что это шум.
А в начале появляется шум. Даже не шум, а куча г.
Кстати, про RAII слышал?


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


И зачем это нужно?


C>>Для программиста не пофиг, так как нельзя с первого взгляда увидеть, где переменная получает значение.

_>Так какие проблемы если так надо можно добавть резервное слово для первого присвоения скажем let. Оно будет единообразно указывать на первое определение.

А, про RAII таки слышал, уже лучше?
И зачем добавлять это слово?
Придумал какие-то сложности на ровном месте, решая какую-то непонятную проблему.

Опять же. Определение переменной по месту экономит стек. Сейчас это не большая проблема на современных компиляторах, но раньше с этим было хуже



C>>Ну и с иммутабельностью по умолчанию оно тоже никак не дружит.

_>С какого перепоя. Компилятору всё равно где объявление. Так что оно будет работать как и работало.
_>
_>SomeTypeWithLongNameAndAlotOfParametersAndNamespaces somevar;
_>auto v1,v2,v3,v4;
_>....

_>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
_>


Какой замечательный код, который позволяет легко нарваться на неинициализированную переменную
Вам как-бы показали сцыкливое мурло российской оппозиции — вот оно
Автор: Министр Промышленности
Дата: 17.10 22:57
!
Re[6]: Чем плох Паскаль?
От: Marty Пират  
Дата: 15.06.19 21:34
Оценка:
Здравствуйте, T4r4sB, Вы писали:


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

TB>А ещё переменная может быть нужна лишь в одной из веток алгоритма. А в другой ветке нужна другая переменная того же типа. И в итоге получаем либо распухший список переменных в начале функции, либо вредную привычку вместо index для одной ветки и tmp для другой заводить одну specail_int и использовать её везде. Сейчас вы скажете, надо функции мельче делать?

Да, я когда учился писать, не знал, что в тогдашних сях можно объявлять можно было объявлять переменные в любых {}, а не только в начале функции. И когда функции по сто раз переписывались, то куча переменных в начале распухала что ппц. А разбираться, что оставить, что нет, было неохота. Ну и с паскалем та же проблема была
Вам как-бы показали сцыкливое мурло российской оппозиции — вот оно
Автор: Министр Промышленности
Дата: 17.10 22:57
!
Re[14]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 15.06.19 21:46
Оценка:
Здравствуйте, AlexRK, Вы писали:

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

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

История записана

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

N>>Ну вот и дают, например, простановкой атрибутов (ранее — спец. ключевыми словами).
ARK>Ну раз дают, то к чему вопрос был.

К тому, что, повторюсь, особый синтаксис тут задаётся атрибутами и ключевыми словами.
А в варианте Паскаля меняется сам парсер.

N>>А зачем при этом менять метод парсинга?


ARK>Метод парсинга не меняется. Точка означает завершение модуля.


Зачем она нужна тогда? Есть EOF уровня файла. Есть блок begin-end вне пределов любых функций.
Что будет, если сделать комментарии после этой точки? Всё сломается или проигнорирует?
Если второе, то зачем эта точка вообще была нужна?

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

N>>И пишет тоже, представь себе. И он вполне способен написать и увидеть слово main.
ARK>Э... ну и? Слово program он тоже способен написать и увидеть, чем оно хуже?

Так program или модуль?

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

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

Он так начинался.

ARK>Ну и да — повторял кто что или не повторял — тоже не особо показатель. Куча языков слепо повторяла и повторяет вредные или убогие концепции (см. ошибка на миллиард долларов или С-like switch с провалами или синтаксическим мусором).


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


ARK>x = a + (b * c);


ARK>Сразу беглым взглядом четко видно структуру выражения.


Ню ню. Не уверен, что любая команда поддержит такое. Скорее — наоборот.

ARK>Кстати, многие языки и вовсе не имеют приоритета операторов — smalltalk, prolog, lisp, pony, наверняка еще кучу забыл.


Ну так не поэтому ли они не получили популярности?
Re[3]: Чем плох Паскаль?
От: elmal  
Дата: 15.06.19 22:12
Оценка:
Здравствуйте, ksandro, Вы писали:

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

В том то и дело что это было когда то . Причем очень давно. Для тех времен да, Delphi был неплохим выбором для тех, кому нужно было что то налабать, при этом не являясь профессиональным программистом. Сейчас уже даже в этой нише лучше от дельфей держаться подальше.
Re[10]: Чем плох Паскаль?
От: alpha21264 СССР  
Дата: 16.06.19 01:08
Оценка:
Здравствуйте, Ops, Вы писали:

Ops>Может производные тоже выкинуть из школьной программы?


К сожалению, уже выкинули.
http://s19.rimg.info/0871fde0709f1bd37b3b012eb22a4583.gif
Течёт вода Кубань-реки куда велят большевики.
Re[11]: Чем плох Паскаль?
От: pagid Россия  
Дата: 16.06.19 01:30
Оценка:
Здравствуйте, alpha21264, Вы писали:

A>К сожалению, уже выкинули.

Ну не знаю, что-то сомнительно.

Смотрю учебник Мордковича, вижу изучение производных в 10 классе. Смотрю учебник Никольского, вижу производные в 11 классе.
Re[3]: Чем плох Паскаль?
От: Mr.Delphist  
Дата: 16.06.19 01:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Не подходит. После Паскаля приходится потом долго вправлять моск в правильную сторону.


Простите, а что за "неправильная" такая сторона у Паскаля? Я вот вообще с Бейсика начинал, много их разных у меня было (Вильнюс, Спектрум, кучка ещё всяких диалектов). Вдруг тоже что-то вправить надо — а не замечаю...

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


Но берут-то почему? Подскажу: там есть ругательные буквы БЛ..., есть кусочек ругательного слова ...ИОТ, хотя в целом само слово — хорошее
Re[2]: Чем плох Паскаль?
От: MamutArGud  
Дата: 16.06.19 01:46
Оценка:
scf>НО — для начального обучениния избыток парадигм вреден. К примеру, вот что входило в мою школьную программу:

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

scf>- процедуры, функции


Вот только за это Паскаль надо выкидывать и забывать как страшный сон. Только виртовские детища, емнип, на ровном месте создают из одной сужности (функция), две. Иди, попробуй объясни ее ... да хоть кому бы то ни было.

scf>Теперь о плюсах Паскаля:

scf>- программы не требуют ни `public static void main`, ни хитрого кода инициализации консоли/окна/графики

Зато нужны другие вещи, которые надо только зазубрить

scf>- простой удобный интерактивный отладчик, мнгновенная компиляция

scf>- строгий структурированный синтаксис на английском языке, без лишних сокращений типа фигурных скобок и навязанных идиом типа значимых отступов
scf>- строгая типизация
scf>- достаточно низкоуровневый, чтобы рассказывать школьникам про байты, биты, непрерывные многомерные массивы и организацию памяти

С этими плюсами лучше уж Erlang взять
Re[15]: Чем плох Паскаль?
От: AlexRK  
Дата: 16.06.19 03:38
Оценка:
Здравствуйте, netch80, Вы писали:

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

N>>>Ну да, с третьей-четвёртой попытки нашли случай, когда ему есть эквивалент
ARK>>С первой попытки.
N>История записана

Записана, конечно — вот мое первое сообщение на эту тему: http://rsdn.org/forum/education/7470487.1
Автор: AlexRK
Дата: 14.06.19


В Ц/Ц++ то же самое — в do надо обязательно ставить {}, а в других местах — нет.


Меняем "Ц/Ц++" на "C#/Java" и получаем верное утверждение. Про Ц/Ц++ я не знал (собственно, цикл do вообще никогда не использовал), но это не меняет сути — что паскаль далеко не единственный язык с таким подходом.

N>К тому, что, повторюсь, особый синтаксис тут задаётся атрибутами и ключевыми словами.

N>А в варианте Паскаля меняется сам парсер.

Может, какой-то кривой парсер, написанный непонятно кем, и меняется, но я не вижу объективных причин для этого. Терминатором функции или программы служит end, а не последующий символ.

N>Что будет, если сделать комментарии после этой точки? Всё сломается или проигнорирует?


Где именно — в классическом паскале? Не знаю. Скорее всего, второе.

N>Зачем она нужна тогда? Есть EOF уровня файла. Есть блок begin-end вне пределов любых функций.

N>Если второе, то зачем эта точка вообще была нужна?

Для строгости и лучшей читаемости кода, я так полагаю. Вот начало, вот конец.

Можно и без точки обойтись. Можно без точек с запятой после каждой строки. Можно без блоков begin/end или {}. Это всё вопрос вкуса. Вирт сделал язык строгим в такой степени, в какой посчитал нужным.

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

ARK>>Э... ну и? Слово program он тоже способен написать и увидеть, чем оно хуже?
N>Так program или модуль?

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

ARK>>x = a + (b * c);

ARK>>Сразу беглым взглядом четко видно структуру выражения.
N>Ню ню. Не уверен, что любая команда поддержит такое. Скорее — наоборот.

Вполне возможно. А может и нет. Такие утверждения лучше обосновывать — скажем, цитатами из Code Style известных проектов.

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

ARK>>Кстати, многие языки и вовсе не имеют приоритета операторов — smalltalk, prolog, lisp, pony, наверняка еще кучу забыл.

N>Ну так не поэтому ли они не получили популярности?

Я считаю, что это крайне маловероятно. Вопрос популярности языков вообще мало коррелирует с их особенностями, по-моему.
Re[3]: Чем плох Паскаль?
От: AlexRK  
Дата: 16.06.19 03:45
Оценка:
Здравствуйте, MamutArGud, Вы писали:

MAG>Вот только за это Паскаль надо выкидывать и забывать как страшный сон. Только виртовские детища, емнип, на ровном месте создают из одной сужности (функция), две. Иди, попробуй объясни ее ... да хоть кому бы то ни было.


Отчего ж, не только виртовские создают из одной сущности две. Страуструповские, ричекернигановские, хейлсберговские, гослинговские детища — они все тоже туда же. Иди попробуй объясни, зачем в сикраше Action и Func ... да хоть кому бы то ни было. Выкинуть и забыть этот весь шлак как страшный сон!
Отредактировано 16.06.2019 3:46 AlexRK . Предыдущая версия .
Re[9]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 04:00
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

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


N>>Это ваша религия говорит?


S>Да


Ну тогда настоятельно предлагаю обойтись без неё и перейти к аргументации логикой и фактами.

N>>И она хоть как-то это пытается обосновать?

N>>Чем плохо иметь и использовать тип данных "хранилище ключ-значение"?

S>Иметь и использовать типы данных — это прекрасно. Не прекрасно засирать этим голову школьникам (и, кстати, школьницам) в обязательном порядке.


Что именно засирательного тут я предложил?

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


S>Да. Не упираться в суммы чётных элементов, потому что это массивы, а массивы — тоже лишнее.


Серьёзно? Даже массивы — лишнее?

S> Сумму чётных элементов последователности, или предел последовательности, или что-то такое.


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

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


А это и не обязательно на таком уровне давать. Достаточно принципа "вот ключи, а вот значения при них".
Re[4]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 05:37
Оценка:
Здравствуйте, borga, Вы писали:

B>Это все глупости я даже не буду опровергать.

B>Человек вполне конкретно расписал вот тут
Автор: scf
Дата: 16.06.19
: вникайте до просветления!


А, то есть тоже аргументов у вас нет, а есть религия.
Спасибо, вопросов нет.
Re[11]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 05:42
Оценка:
Здравствуйте, AlexRK, Вы писали:

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


N>>Пусть по одной ветке тип получает значение complex<float>, по другой double, по третьей — string.

N>>Какой тип будем дедуцировать?

ARK>Вопрос не ко мне, но очевидно же, что compile error.


То есть надо все ветки привести явно к одному типу значения (или к совместимым с минимальными различиями).
Ну вот после этого и видно, что явное задание типа целевой переменной — проще и эффективнее, как минимум в заметной части случаев.
Re[4]: Чем плох Паскаль?
От: qwertyuiop Российская Империя  
Дата: 16.06.19 06:19
Оценка:
Здравствуйте, netch80, Вы писали:

N>Ну для обучения ещё неизвестно, что лучше.

N>Циклы в сишном стиле — тут надо зазубрить идиомы, что переменная итератора всегда одна и та же (а иначе будет долго втыкать, что не так в каком-нибудь for (i = 0; ii < 100; ++i)), или, если это нарушается, нужно смотреть внимательнее, что происходит.

Если это нарушается, то компилятор об этом скажет. Но зато Си позволяет вообще не привязываться к переменной цикла, а проверять условие выхода другими способами, которые лишь косвенно связаны с переменной цикла.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Re[2]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 16.06.19 06:44
Оценка:
Здравствуйте, scf, Вы писали:

scf>НО — для начального обучениния избыток парадигм вреден. К примеру, вот что входило в мою школьную программу:

scf>- понятие алгоритма
scf>- операторы, переменные, типы, условия, циклы
scf>- процедуры, функции
scf>- структуры данных: массивы, строки, списки, деревья
Вот тут начинаются проблемы со списков. В школьной программе их нет.

scf>- алгоритмы: поиск элементов в масивах, обход списков, обход деревьев, двоичный поиск, решение уравнений методом деления пополам

И на йух это не надо.

scf>- ascii графика (типа распечатать таблицу умножения)

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

scf>Этого списка достаточно, чтобы загрузить школьников до 11 класса включительно. Надеюсь, никто не будет спорить, что а) всё перечисленное нужно и б) никакие парадигмы и библиотеки для этого не нужны.

Ещё их можно загрузить уроками по строевому шагу. Речь идёт не о "загрузить", а об обучении.

scf>- программы не требуют ни `public static void main`, ни хитрого кода инициализации консоли/окна/графики

scf>- простой удобный интерактивный отладчик, мнгновенная компиляция
Python.

scf>- строгий структурированный синтаксис на английском языке, без лишних сокращений типа фигурных скобок и навязанных идиом типа значимых отступов

Синтаксис не строгий.

scf>- строгая типизация

Не строгая.

scf>- достаточно низкоуровневый, чтобы рассказывать школьникам про байты, биты, непрерывные многомерные массивы и организацию памяти

А зачем?
Sapienti sat!
Re[9]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 16.06.19 06:50
Оценка:
Здравствуйте, netch80, Вы писали:

C>>В С есть удобный разыменователь: ptr->x, в Паскале его нет.

N>C: obj.x, ptr->x
N>Pascal: obj.x, ptr^.x
N>тебя "^." настолько смущает синтаксически? Форма стрелки направо критична?
Да, так как разыменователь отличается от всего остального в Паскале.

C>>Да, но только это всё скрыто магией. Совершенно непонятно причём там указатели.

N>Как это зачем? Указатель на выделенную динамическую область. Или ты о чём?
Динамические массивы в Паскале работают через setlength. Не очень понятно как.

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

C>>Ну вот потому С как раз очень помогает понять указатели, в отличие от Паскаля.
N>Я бы не сказал, что возможность a[i] === i[a] тут как-то существенно помогает
Это как раз неважно. Важно то, что в С очень очевидная связь между массивами и памятью. Массив — это просто набор элементов, которые идут один за другим. С арифметикой указателей на них, работающей очевидным образом.

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

N>Не-а. Чтобы понять простую идею "указатель это адрес", это всё не нужно.
N>Чтобы понять арифметику указателей — тоже. Её по любому надо явно объяснить, и этого достаточно.
Мне из личного опыта — было нужно. Я слышал и другие подобные истории.
Sapienti sat!
Re[8]: Чем плох Паскаль?
От: pagid Россия  
Дата: 16.06.19 06:50
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Когда-то так и было. Первые компиляторы Паскаля были однопроходными, что и требовало объявлять переменные в начале. В результате поклонники секты Свидетелей Вирта эту багофичу вознесли в ранг Евангелия.

Дело скорее не в однопроходности самой по себе, а в том, что в Паскале есть вложенные функции, и объявление переменных после них приведет не только к необходимости не однопроходного компилятора, но и логичным вопросам "что за ... ?"
Понимаю разумеется, что не будь этих вложенных функций Вирт все равно бы принудил объявлять переменные в отдельном разделе, но он точно так же принудил это делать, если бы изначально компилятор пришлось сделать не однопроходным. Хотя он все равно равно бы его сделал однопроходным
Re[6]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 16.06.19 07:03
Оценка:
Здравствуйте, Marty, Вы писали:

M>Я бы не сказал, что это шум.

M>А в начале появляется шум. Даже не шум, а куча г.
Это не шум это объявление ограничений. В рамках которых описывается дальнейшая программа.

M>Кстати, про RAII слышал?

Если вам говорили что RAII вершина управления ресурсами то от вас многое утаили.

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

M>И зачем это нужно?
Незнаю но многие упорно хотят видеть где переменная впервые использеутся. С этим спокойно спраиться IDE просто подсвечивая имя под курсором по всему тексту.
  Скрытый текст
https://i.imgur.com/glCtE2Y.png

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

...
M>Какой замечательный код, который позволяет легко нарваться на неинициализированную переменную
Как раз нет. Посмотрите язык zig если ваша переменная должна быть не инициализированны то это надо объявить явно иначе вообще не компилируется.
Re[4]: Чем плох Паскаль?
От: MamutArGud  
Дата: 16.06.19 08:04
Оценка:
MAG>>Вот только за это Паскаль надо выкидывать и забывать как страшный сон. Только виртовские детища, емнип, на ровном месте создают из одной сужности (функция), две. Иди, попробуй объясни ее ... да хоть кому бы то ни было.

ARK>Отчего ж, не только виртовские создают из одной сущности две. Страуструповские, ричекернигановские, хейлсберговские, гослинговские детища


В каком месте в C, C++, Java и т.п. есть разделение на процедуры и функции?

ARK>- они все тоже туда же. Иди попробуй объясни, зачем в сикраше Action и Func ... да хоть кому бы то ни было. Выкинуть и забыть этот весь шлак как страшный сон!


Это скорее из-за ущербности системы типов и дизайна. Потому что сигнатура `Func` вот такая:

TResult Func<in T,out TResult>(T arg);


понятно, что нельзя иметь
out void


Но да. Лажа в какой-то мере такая же, что и function/procedure в Паскале. Другое дело, что в Паскале с ними сталкиваешься сразу, а в C# можно долго не знать ни про Action ни про Func
Re[5]: Чем плох Паскаль?
От: AlexRK  
Дата: 16.06.19 09:05
Оценка:
Здравствуйте, MamutArGud, Вы писали:

MAG>В каком месте в C, C++, Java и т.п. есть разделение на процедуры и функции?


Ну как же. Так называемый "тип" void — это вот оно и есть.

ARK>>- они все тоже туда же. Иди попробуй объясни, зачем в сикраше Action и Func ... да хоть кому бы то ни было. Выкинуть и забыть этот весь шлак как страшный сон!

MAG>Это скорее из-за ущербности системы типов и дизайна.

Безусловно. Но по факту это и есть деление на процедуры и функции.

MAG>понятно, что нельзя иметь
out void


Да много чего нельзя. Переменную типа void нельзя объявить. Нельзя вот так сделать (слегка обобщенный псевдокод):

function Combine<T...>(a: function() T..., b: function(T...))      // принимает две функции, которые можно скомбинировать - вторая принимает то же, что возвращает первая
{
    var result: T...;        // кортеж! может быть одна переменная, несколько переменных или НОЛЬ переменных!
    result := a();
    b(result);
}

function A1() result: int           // ничего не принимает, возвращает целое число
{
    Print("A1 ");
    return 33;
}

function B1(param: int)             // принимает целое число, ничего не возвращает
{
    Print("B1 ");
    Print(param);
}

function A2()                       // ничего не принимает и не возвращает (как будто принимает и возвращает "ничего")
{
    Print("A2 ");
}

function B2()                       // ничего не принимает и не возвращает (как будто принимает и возвращает "ничего")
{
    Print("B2 ");
}

function Main()
{
    Combine(A1, B1);       // печатает "A1 B1 33"

    Combine(A2, B2);       // И ЭТО ТОЖЕ РАБОТАЕТ!!! печатает "A2 B2 "
}


Вот такого — нету, а это и есть самое главное. "void" — это не тип, а заглушка. Это и есть "procedure", только записывается короче.

MAG>Но да. Лажа в какой-то мере такая же, что и function/procedure в Паскале. Другое дело, что в Паскале с ними сталкиваешься сразу, а в C# можно долго не знать ни про Action ни про Func


Так и с void и его особенностями тоже сразу сталкиваешься.
Отредактировано 16.06.2019 9:20 AlexRK . Предыдущая версия . Еще …
Отредактировано 16.06.2019 9:17 AlexRK . Предыдущая версия .
Re[10]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 16.06.19 11:49
Оценка:
Здравствуйте, netch80, Вы писали:

S>>Иметь и использовать типы данных — это прекрасно. Не прекрасно засирать этим голову школьникам (и, кстати, школьницам) в обязательном порядке.


N>Что именно засирательного тут я предложил?


Хештаблицы и прочие структуры данных сложнее, чем переменная в смысле integer или double.

N>Серьёзно? Даже массивы — лишнее?


Да.

S>> Сумму чётных элементов последователности, или предел последовательности, или что-то такое.


N>Ну если в языке будет абстрактная последовательность, то он станет чем-то вроде Хаскеля.


Никаких абстрактных последовательностей, а просто циклом вычислить сумму элементов ряда, типа a(n)=1/n

N>А это и не обязательно на таком уровне давать. Достаточно принципа "вот ключи, а вот значения при них".


Так же не будет. Обязательно потащится всякая алгоритмическая сложность и прочее.
Отредактировано 16.06.2019 14:44 Sharowarsheg . Предыдущая версия .
Re[5]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 12:58
Оценка:
Здравствуйте, qwertyuiop, Вы писали:

N>>Ну для обучения ещё неизвестно, что лучше.

N>>Циклы в сишном стиле — тут надо зазубрить идиомы, что переменная итератора всегда одна и та же (а иначе будет долго втыкать, что не так в каком-нибудь for (i = 0; ii < 100; ++i)), или, если это нарушается, нужно смотреть внимательнее, что происходит.

Q>Если это нарушается, то компилятор об этом скажет.


Не на каждый случай. Только если такой переменной нет или ещё в паре аналогичных банальных случаев.

Q> Но зато Си позволяет вообще не привязываться к переменной цикла, а проверять условие выхода другими способами, которые лишь косвенно связаны с переменной цикла.


Так они все позволяют. if (условие) break; внутри цикла.
Re[3]: Чем плох Паскаль?
От: MamutArGud  
Дата: 16.06.19 12:58
Оценка:
C>>В современном варианте было бы лучше что-то типа Питона с графической средой. Или как вариант: https://www.apple.com/swift/playgrounds/ — лучшее, что я вообще видел для детей.

Pzz>Мне кажется, использование в качестве первого языка, языка с динамической типизацией, уродует головной мозг человека навсегда.


В каком месте Swift динамически типизиурем?
Re[4]: Чем плох Паскаль?
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.06.19 15:01
Оценка:
Здравствуйте, MamutArGud, Вы писали:

C>>>В современном варианте было бы лучше что-то типа Питона с графической средой. Или как вариант: https://www.apple.com/swift/playgrounds/ — лучшее, что я вообще видел для детей.


Pzz>>Мне кажется, использование в качестве первого языка, языка с динамической типизацией, уродует головной мозг человека навсегда.


MAG>В каком месте Swift динамически типизиурем?


"что-то типа Питона"
Re[2]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 15:44
Оценка:
Здравствуйте, scf, Вы писали:

scf>Теперь о плюсах Паскаля:

scf>- программы не требуют ни `public static void main`, ни хитрого кода инициализации консоли/окна/графики

Если эти стандартные обрамления поставляются готовыми, они ученикам не мешают.
Но если есть смысл в их изменении (а он есть, где можно менять), то надо иметь возможность их менять и надо, чтобы была возможность у учеников заинтересоваться ими.
Жёсткое begin и поехали, как в случае Паскаля, тут не помогает.

scf>- простой удобный интерактивный отладчик, мнгновенная компиляция


Видимо, вы рассуждаете про досовский Turbo Pascal. Это уже никуда не годится.

scf>- строгий структурированный синтаксис на английском языке, без лишних сокращений типа фигурных скобок и навязанных идиом типа значимых отступов


Чем это фигурные скобки "лишние сокращения"? Обоснуйте.
Значимые отступы — хороший способ форсирования обязательных структурных отступов.
Можно и не значимыми, лишь бы средство форматирования шло в обязательном комплекте.

scf>- строгая типизация


Не очень строгая, вообще-то.
Конверсии к более узкому целому или к плавающей — проходят молча.
Аналогов __builtin_add_overflow() не водится и не планируется.
Контроль ошибок слабый, если не разрешать обработку исключений стиля Delphi.

scf>- достаточно низкоуровневый, чтобы рассказывать школьникам про байты, биты, непрерывные многомерные массивы и организацию памяти


scf>И о минусах:


scf>25х80, текстовый интерфейс и запуск через dosbox — некруто.


Ну так есть много новых средств типа FreePascal, Pascal.ABC...
Но они страдают теми же системными проблемами языка.
Re[9]: Чем плох Паскаль?
От: Ops Россия  
Дата: 16.06.19 17:28
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

S>Иметь и использовать типы данных — это прекрасно. Не прекрасно засирать этим голову школьникам (и, кстати, школьницам) в обязательном порядке.


Это куда проще многих других школьных концепций. Может производные тоже выкинуть из школьной программы?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[7]: Чем плох Паскаль?
От: Александр Кузнецов Россия  
Дата: 16.06.19 17:35
Оценка:
Здравствуйте, netch80, Вы писали:

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


N>- а условия i <= 9 и i < 10 это одно и то же? (в спокойной обстановке они сами это скажут и посмеются, что кто-то не понимает, но когда сам начинаешь писать, нервы всё сбивают)


от 0 до 9 — это включая 9, или нет? ) Самое смешное, что семантически "до" допускает гораздо более неоднозначную трактовку, чем <, или <=. И как раз в Паскале это надо "просто запомнить", так как понять невозможно.

На самом деле в любом языке есть куча вещей, которые понять либо невозможно и надо тупо запоминать, либо можно, но только уже постигнув дзен этого языка. Но проблема в том, что сейчас подавляющее большинство языков С-подобные. Т.е. абстрактному студенту сперва надо запомнить специфику синтаксиса одного языка, а потом оперативно переключаться на другой. И выбор, к сожалению, не выглядит как: "учить на Паскале", или "учить на С-подобном языке". Он выглядит так: "Учить на С-подобном языке сразу" или "Учить на Паскале, а потом тут же переучивать на С-подобное".
Да, глупо отрицать, что Паскаль лучше подходит для обучения (он, в конце концов, для этого и задумывался). Проблема в том, что пара-тройка проблемных мест С-подобного синтаксиса, с которыми может столкнуться новичок, не перекрывают необходимости учить заново новый язык, практически полностью пуская на свалку знания по старому.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Re[10]: Чем плох Паскаль?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.06.19 17:36
Оценка:
Здравствуйте, pagid, Вы писали:

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


S>> Программирование это инструмент. Например нельзя изучать математику без высшей математики.

P>Значит школьники зря математику на уроках учат. Им бы сначала высшую преподнести, тогда можно и школьной заниматься. Или ты что-то другое называешь изучением, а может быть и математикой
Спасибо. Поправлю. Хотел написать "нельзя изучать физику без высшей математики"
и солнце б утром не вставало, когда бы не было меня
Re[11]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 19:20
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

S>>>Иметь и использовать типы данных — это прекрасно. Не прекрасно засирать этим голову школьникам (и, кстати, школьницам) в обязательном порядке.

N>>Что именно засирательного тут я предложил?
S>Хештаблицы и прочие структуры данных сложнее, чем переменная в смысле integer или double.

Зато это принципиальная возможность, которая всегда будет использована на практике и полезна для задач.

N>>Серьёзно? Даже массивы — лишнее?

S>Да.

И что тогда останется от всей тематики? Будет ли там на чём вообще делать реальное обучение?

S>>> Сумму чётных элементов последователности, или предел последовательности, или что-то такое.

N>>Ну если в языке будет абстрактная последовательность, то он станет чем-то вроде Хаскеля.
S>Никаких абстрактных последовательностей, а просто циклом вычислить сумму элементов ряда, типа a(n)=1/n

Вы намеренно дали пример на расходящийся ряд?

N>>А это и не обязательно на таком уровне давать. Достаточно принципа "вот ключи, а вот значения при них".

S>Так же не будет. Обязательно потащится всякая алгоритмическая сложность и прочее.

Почему? Это как раз можно на базовом уровне не вспоминать. Только на первом из продвинутых.
Re[8]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 19:22
Оценка:
Здравствуйте, Александр Кузнецов, Вы писали:

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

N>>- а условия i <= 9 и i < 10 это одно и то же? (в спокойной обстановке они сами это скажут и посмеются, что кто-то не понимает, но когда сам начинаешь писать, нервы всё сбивают)
АК>от 0 до 9 — это включая 9, или нет? ) Самое смешное, что семантически "до" допускает гораздо более неоднозначную трактовку, чем <, или <=. И как раз в Паскале это надо "просто запомнить", так как понять невозможно.

Ну потому и есть "до" "включая" и "не включая".

АК>На самом деле в любом языке есть куча вещей, которые понять либо невозможно и надо тупо запоминать, либо можно, но только уже постигнув дзен этого языка. Но проблема в том, что сейчас подавляющее большинство языков С-подобные. Т.е. абстрактному студенту сперва надо запомнить специфику синтаксиса одного языка, а потом оперативно переключаться на другой. И выбор, к сожалению, не выглядит как: "учить на Паскале", или "учить на С-подобном языке". Он выглядит так: "Учить на С-подобном языке сразу" или "Учить на Паскале, а потом тут же переучивать на С-подобное".


Да.

АК>Да, глупо отрицать, что Паскаль лучше подходит для обучения (он, в конце концов, для этого и задумывался).


Нет. Потому что задумка оказалась кривой по куче моментов.
Но так как в IT побеждает не лучшее, а первое из того, что минимально приемлемо и раскручено, то Pascal пошёл, а обновления в виде Modula — нет, они опоздали.

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


Да.
Re[12]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 16.06.19 19:27
Оценка:
Здравствуйте, netch80, Вы писали:

S>>Хештаблицы и прочие структуры данных сложнее, чем переменная в смысле integer или double.


N>Зато это принципиальная возможность, которая всегда будет использована на практике и полезна для задач.


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

N>>>Серьёзно? Даже массивы — лишнее?

S>>Да.

N>И что тогда останется от всей тематики? Будет ли там на чём вообще делать реальное обучение?


Ворд-эксель, и паскаль в объёме чуть большем hello world. Даже ворд с экселем в нормальном объеме я не уверен, что можно успеть.

S>>>> Сумму чётных элементов последователности, или предел последовательности, или что-то такое.

N>>>Ну если в языке будет абстрактная последовательность, то он станет чем-то вроде Хаскеля.
S>>Никаких абстрактных последовательностей, а просто циклом вычислить сумму элементов ряда, типа a(n)=1/n

N>Вы намеренно дали пример на расходящийся ряд?


Да. Не будем же мы выбрасывать из школьной программы арифметическое переполнение? Или выбросить?

N>>>А это и не обязательно на таком уровне давать. Достаточно принципа "вот ключи, а вот значения при них".

S>>Так же не будет. Обязательно потащится всякая алгоритмическая сложность и прочее.

N>Почему? Это как раз можно на базовом уровне не вспоминать. Только на первом из продвинутых.


Нет. Не верю я в то, что это остановится на каких-то разумных пределах. Только резать, резать, и резать.
Re[10]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 19:34
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>В С есть удобный разыменователь: ptr->x, в Паскале его нет.

N>>C: obj.x, ptr->x
N>>Pascal: obj.x, ptr^.x
N>>тебя "^." настолько смущает синтаксически? Форма стрелки направо критична?
C>Да, так как разыменователь отличается от всего остального в Паскале.

Постфиксностью? И что в этом плохого?

C>>>Да, но только это всё скрыто магией. Совершенно непонятно причём там указатели.

N>>Как это зачем? Указатель на выделенную динамическую область. Или ты о чём?
C>Динамические массивы в Паскале работают через setlength. Не очень понятно как.

std::vector::reserve и аналоги. Что непонятного-то?
Ну да, реализовано в языке, а не библиотеке.

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

C>>>Ну вот потому С как раз очень помогает понять указатели, в отличие от Паскаля.
N>>Я бы не сказал, что возможность a[i] === i[a] тут как-то существенно помогает
C>Это как раз неважно. Важно то, что в С очень очевидная связь между массивами и памятью. Массив — это просто набор элементов, которые идут один за другим. С арифметикой указателей на них, работающей очевидным образом.

Так тут то же самое. Только не всегда дают сам указатель.

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

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

Лично нужно было a[i] === i[a]?
Re[7]: Чем плох Паскаль?
От: AlexRK  
Дата: 16.06.19 19:54
Оценка:
Здравствуйте, netch80, Вы писали:

N>Не так. В исходном Pascal у функции, кроме возвращаемого значения, ещё одно свойство: отсутствие побочных эффектов — нельзя присваивать ничего за пределами, нет var-параметров. Сейчас это принято называть, что функция чистая (pure).

N>В Turbo версии и вслед за ней во всех реальных это, насколько помню, похерили. С этого момента (и особенно с появлением var-параметров у функций) и получилось, что procedure f === void f(), а function f: type === type f, и больше принципиальной разницы нет.
N>Но вначале оно было жёстко принципиальное.

Это тоже верно, но я сейчас говорю про текущую ситуацию — с чистотой функций никто не заморачивается (очень зря), но деление все равно есть из-за псевдотипа void, не позволяющего работать однотипно с произвольными функциями.

N>2. Если уже говорить про подобные возможности, то надо вспоминать и возврат не одного значения из функции, а многих. В C++, считаем, есть (хоть и криво — ни один ABI это ещё не позволяет напрямую; std::pair, std::tuple приводят к возврату структуры через скрытый параметр — указатель), и можно использовать (да хоть монады на нём строить). В Паскале нет и не ожидается.


Я не большой знаток C++ , но не помню, что в нем это "есть". Чтобы использовать пары и туплы для комбинирования, надо, чтобы их не только возвращали, но и принимали входными параметрами, разве нет? Или можно НАПРЯМУЮ сунуть тупл (2, "test") в функцию "void Func(int a, string b)", т.е. вызвать как "Func(myTuple);"? Если нельзя, то все эти пары с туплами нельзя считать за что-то особенное. Такое и в паскале есть — возвращай да принимай любые структуры, строй из них монады.
Re[7]: Чем плох Паскаль?
От: pagid Россия  
Дата: 16.06.19 20:06
Оценка:
Здравствуйте, netch80, Вы писали:


N>Не так. В исходном Pascal у функции, кроме возвращаемого значения, ещё одно свойство: отсутствие побочных эффектов — нельзя присваивать ничего за пределами, нет var-параметров. Сейчас это принято называть, что функция чистая (pure).

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

N>2. Если уже говорить про подобные возможности, то надо вспоминать и возврат не одного значения из функции, а многих. В C++, считаем, есть (хоть и криво — ни один ABI это ещё не позволяет напрямую; std::pair, std::tuple приводят к возврату структуры через скрытый параметр — указатель), и можно использовать (да хоть монады на нём строить). В Паскале нет и не ожидается.

Возвращай запись (record) или их нельзя было возвращать? вот это точно не помню.
Re[13]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 22:07
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

S>>>Хештаблицы и прочие структуры данных сложнее, чем переменная в смысле integer или double.

N>>Зато это принципиальная возможность, которая всегда будет использована на практике и полезна для задач.
S>Теми, кто пойдет в хирурги, эта возможность не будет использована никогда.

Именно эта возможность будет постоянно использоваться, если он вообще будет что-то автоматизировать.
DB-like операции "посмотреть/уточнить параметры пациента".
Управление операциями типа "если появится кровь вот в этом сегменте изображения, подать тревогу" — и таких сегментов обычно несколько, и их желательно называть.
Ну и так далее.

S>>>>> Сумму чётных элементов последователности, или предел последовательности, или что-то такое.

N>>>>Ну если в языке будет абстрактная последовательность, то он станет чем-то вроде Хаскеля.
S>>>Никаких абстрактных последовательностей, а просто циклом вычислить сумму элементов ряда, типа a(n)=1/n
N>>Вы намеренно дали пример на расходящийся ряд?
S>Да. Не будем же мы выбрасывать из школьной программы арифметическое переполнение? Или выбросить?

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

N>>>>А это и не обязательно на таком уровне давать. Достаточно принципа "вот ключи, а вот значения при них".

S>>>Так же не будет. Обязательно потащится всякая алгоритмическая сложность и прочее.
N>>Почему? Это как раз можно на базовом уровне не вспоминать. Только на первом из продвинутых.
S>Нет. Не верю я в то, что это остановится на каких-то разумных пределах.

Оно всегда останавливается, и сильно раньше разумных пределов. Просто иначе физически не поместить в ослабленные требования к школьникам (которые возникают из-за преподавания ещё в стиле Локка, учителей "на отцепись" и жалоб типа "ой перегружены, не успеваем").
Re[8]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 22:08
Оценка:
Здравствуйте, pagid, Вы писали:

N>>Не так. В исходном Pascal у функции, кроме возвращаемого значения, ещё одно свойство: отсутствие побочных эффектов — нельзя присваивать ничего за пределами, нет var-параметров. Сейчас это принято называть, что функция чистая (pure).

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

Я ж говорил — у Borland многие ограничения уже ослаблены.

N>>2. Если уже говорить про подобные возможности, то надо вспоминать и возврат не одного значения из функции, а многих. В C++, считаем, есть (хоть и криво — ни один ABI это ещё не позволяет напрямую; std::pair, std::tuple приводят к возврату структуры через скрытый параметр — указатель), и можно использовать (да хоть монады на нём строить). В Паскале нет и не ожидается.

P>Возвращай запись (record) или их нельзя было возвращать? вот это точно не помню.

Вроде можно. Но это тот же самый костыль.
Re[8]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 22:11
Оценка:
Здравствуйте, AlexRK, Вы писали:

N>>В Turbo версии и вслед за ней во всех реальных это, насколько помню, похерили. С этого момента (и особенно с появлением var-параметров у функций) и получилось, что procedure f === void f(), а function f: type === type f, и больше принципиальной разницы нет.

N>>Но вначале оно было жёстко принципиальное.
ARK>Это тоже верно, но я сейчас говорю про текущую ситуацию — с чистотой функций никто не заморачивается (очень зря), но деление все равно есть из-за псевдотипа void, не позволяющего работать однотипно с произвольными функциями.

А чем он так мешает? Ну, присвоить результат нельзя. Так и при не-void его присваивать необязательно.

N>>2. Если уже говорить про подобные возможности, то надо вспоминать и возврат не одного значения из функции, а многих. В C++, считаем, есть (хоть и криво — ни один ABI это ещё не позволяет напрямую; std::pair, std::tuple приводят к возврату структуры через скрытый параметр — указатель), и можно использовать (да хоть монады на нём строить). В Паскале нет и не ожидается.

ARK>Я не большой знаток C++ , но не помню, что в нем это "есть". Чтобы использовать пары и туплы для комбинирования, надо, чтобы их не только возвращали, но и принимали входными параметрами, разве нет? Или можно НАПРЯМУЮ сунуть тупл (2, "test") в функцию "void Func(int a, string b)", т.е. вызвать как "Func(myTuple);"?

Можно.
Даже в штатной библиотеке какой-нибудь std::map::insert принимает std::pair<> как аргумент.
Re: Чем плох Паскаль?
От: Мёртвый Даун Чехия  
Дата: 16.06.19 22:20
Оценка:
Здравствуйте, Cicero, Вы писали:

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

C>Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!

Мне кажется это и есть как раз идеальный язык для обучения! Именно обучения, т.е. получения первоначальных познакний и навыков.
Мне нравился Паскаль, самые лучшие воспоминания остались от тех времен. Конечно может потому что и телки моложе были и трава зеленее.
Эмоционально нестабилен...
Re[14]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 16.06.19 22:25
Оценка:
Здравствуйте, netch80, Вы писали:

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


S>>>>Хештаблицы и прочие структуры данных сложнее, чем переменная в смысле integer или double.

N>>>Зато это принципиальная возможность, которая всегда будет использована на практике и полезна для задач.
S>>Теми, кто пойдет в хирурги, эта возможность не будет использована никогда.

N>Именно эта возможность будет постоянно использоваться, если он вообще будет что-то автоматизировать.


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

N>DB-like операции "посмотреть/уточнить параметры пациента".

N>Управление операциями типа "если появится кровь вот в этом сегменте изображения, подать тревогу" — и таких сегментов обычно несколько, и их желательно называть.

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

N>>>>>А это и не обязательно на таком уровне давать. Достаточно принципа "вот ключи, а вот значения при них".

S>>>>Так же не будет. Обязательно потащится всякая алгоритмическая сложность и прочее.
N>>>Почему? Это как раз можно на базовом уровне не вспоминать. Только на первом из продвинутых.
S>>Нет. Не верю я в то, что это остановится на каких-то разумных пределах.

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


Мне казалось и когда я учился, и сейчас, что сильно позже, и что сильно не хватает факультативности всякой.
Отредактировано 16.06.2019 22:26 Sharowarsheg . Предыдущая версия .
Re[9]: Чем плох Паскаль?
От: pagid Россия  
Дата: 16.06.19 22:26
Оценка:
Здравствуйте, netch80, Вы писали:

N>Я ж говорил — у Borland многие ограничения уже ослаблены.

Вложенные процедуры/функции были в языке изначально.

N>Вроде можно. Но это тот же самый костыль.

Почему костыль? Напротив — модная возможность возвращать несколько значений это синтаксический сахар.
Re[10]: Чем плох Паскаль?