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

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

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

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

Почему:
Говоря двумя словами: потому что в Паскале минимум неоднозначности синтаксиса.
ИМХО это научит контролировать код более строго.
O tempora! O mores!
Re: Чем плох Паскаль?
От: Klikujiskaaan КНДР  
Дата: 13.06.19 15:14
Оценка: +3 :))) :)
Здравствуйте, Cicero, Вы писали:

C>Почему:

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

В лиспе еще меньше + SICP и HTDP.
А паскаль не нужен по причине того, что после него надо учить другой ЯП для подключения пупса к станку.
Re[2]: Чем плох Паскаль?
От: Слава  
Дата: 13.06.19 15:24
Оценка:
Здравствуйте, Klikujiskaaan, Вы писали:

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


Простите, что?
Re[3]: Чем плох Паскаль?
От: TMU_1  
Дата: 13.06.19 15:48
Оценка: +7
K>>для подключения пупса к станку.
С>Простите, что?



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

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

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

Паскаль ничем не плох. Он прост и строг, для начального обучения программированию это очень хорошие качества.
Re: Чем плох Паскаль?
От: Джеффри  
Дата: 13.06.19 17:10
Оценка: +6
Здравствуйте, 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
Оценка: +4 -1
Изучая промышленный язык, школьник может понемногу участвовать в интересных проектах и использовать огромную общедоступную базу знаний. Изучая Паскаль, он может только копировать с доски.
Ce n'est que pour vous dire ce que je vous dis.
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: Чем плох Паскаль?
От: vsb Казахстан  
Дата: 13.06.19 17:40
Оценка: -1
Паскаль плох тем, что не применяется на практике. Лет 15 назад ещё как-то применялся в дельфи, сейчас совсем сдох. А в остальном хороший язык, да, особенно если ограничиваться оригинальным подмножеством, а не турбо-паскалем. Если нужно учить человека программированию всерьёз, например в университете, паскаль это хороший вариант.
Re[2]: Чем плох Паскаль?
От: AlexRK  
Дата: 13.06.19 17:41
Оценка: +3 -2
Здравствуйте, Джеффри, Вы писали:

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


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

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


Верно.

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


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

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


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

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


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

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


FreePascal работает на любых платформах и полностью совместим с трубопаскалем.
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: Чем плох Паскаль?
От: elmal  
Дата: 13.06.19 18:53
Оценка: +6 -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: Чем плох Паскаль?
От: 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[2]: Чем плох Паскаль?
От: Слава  
Дата: 13.06.19 19:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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

C>Почему:

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

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

Вдруг среди важных задач совершенно внезапно стоит такая мелочь, как не отпугнуть от программирования среднестатистического современного ребенка... Не, ну вдруг?
Re: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 13.06.19 19:26
Оценка: 3 (2) +4
Здравствуйте, 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[2]: Чем плох Паскаль?
От: Слава  
Дата: 13.06.19 19:32
Оценка: :)
Здравствуйте, netch80, Вы писали:

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


Вы забыли ещё про синтаксический оверхед написать.
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[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 Россия http://pzz.livejournal.com/
Дата: 13.06.19 21:45
Оценка: +3
Здравствуйте, Cyberax, Вы писали:

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


Мне кажется, использование в качестве первого языка, языка с динамической типизацией, уродует головной мозг человека навсегда.
Re[2]: Чем плох Паскаль?
От: Pzz Россия http://pzz.livejournal.com/
Дата: 13.06.19 21:51
Оценка:
Здравствуйте, netch80, Вы писали:

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


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

Насколько я могу судить, причина тому — странная причудь Вирта оформлять вызов фукнции без аргументов в виде имени функции без скобок. Отсюда невозможность понять, если такая функция возвращает указатель на функцию, то что имеется ввиду, она сама или возвращаемое ей значение. Ну и как сомнительное решение этпй проблемы — отсутствие возможности вернуть указатель на функцию вообще.
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[3]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 13.06.19 22:58
Оценка: +2
Здравствуйте, kov_serg, Вы писали:

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

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

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

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

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

Но после перехода на С всё стало абсолютно кристально понятно сразу же.
Sapienti sat!
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[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[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[4]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 04:53
Оценка: +1 -1
Здравствуйте, Cyberax, Вы писали:

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

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

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


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

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

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

Потому что значение переменной может зависеть от результата выполнения сложного блока, то есть объявить её со значением до этого блока нельзя.
А ещё переменная может быть нужна лишь в одной из веток алгоритма. А в другой ветке нужна другая переменная того же типа. И в итоге получаем либо распухший список переменных в начале функции, либо вредную привычку вместо index для одной ветки и tmp для другой заводить одну specail_int и использовать её везде. Сейчас вы скажете, надо функции мельче делать?
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]: Чем плох Паскаль?
От: pagid Россия  
Дата: 14.06.19 08:06
Оценка: +1
Здравствуйте, netch80, Вы писали:

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

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


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

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


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

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

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

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

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

Есть же Perl!

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

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

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

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

А в Го массивы, хеши, каналы — это не магическое, не? Синтаксис не странный?
Re[9]: Чем плох Паскаль?
От: T4r4sB Россия  
Дата: 14.06.19 08:16
Оценка: +3
Здравствуйте, kov_serg, Вы писали:

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

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

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

Да любой современный язык — по умолчанию не переменная (var), а val, которой не изменить значение после присваивания. Надеюсь до чистой Java такое вскоре тоже дойдет, это как раз то, что можно исправить, хоть и не полностью. Даже такой капец, как JavaScript — там именно с фичами то не так и плохо, там в другом проблема.
Re: Чем плох Паскаль?
От: Александр Кузнецов Россия  
Дата: 14.06.19 08:47
Оценка: +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[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]: Чем плох Паскаль?
От: koenig  
Дата: 14.06.19 09:13
Оценка: +1
I>>зачем обучать мёртвому языку ?

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



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

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


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


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

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


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


Ну, английский, всё-таки, от латыни произошёл, значительную часть слов и конструкций вполне себе успешно из неё заимствовал, и в некоторых моментах для понимания, "почему так" латынь там вполне себе может помочь.
А вот начинать учить английский с, например, старонорвежского, я бы всё-таки не советовал.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
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[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: Чем плох Паскаль?
От: qwertyuiop Российская Империя  
Дата: 14.06.19 11:29
Оценка:
Здравствуйте, Cicero, Вы писали:

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


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

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


Это примерно как предложить людям ходить исключительно строевым шагом, объясняя это тем, что "так обувь ровнее стаптывается и меньше шансов оступиться". Логика железная, но мало кто на это добровольно согласится.
Ку...
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[6]: Чем плох Паскаль?
От: night beast СССР  
Дата: 14.06.19 11:34
Оценка: +2
Здравствуйте, AlexRK, Вы писали:

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


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


шито?
Re[6]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 11:39
Оценка:
Здравствуйте, 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[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]: Чем плох Паскаль?
От: 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[7]: Чем плох Паскаль?
От: elmal  
Дата: 14.06.19 12:39
Оценка:
Здравствуйте, Пацак, Вы писали:

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

Ну, это не изменение синтаксиса, это его добавление. А вообще, я надеюсь что с появлением Data Types будет заодно и нормальная иммутабельность объектов.
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[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: Чем плох Паскаль?
От: borga  
Дата: 14.06.19 13:17
Оценка: +1
Здравствуйте, Cicero, Вы писали:

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

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

Что же касается более продвинутого уровня.
Вам вот реально важно begin/end или {}?
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 22:26
.

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

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

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

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

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

Чувствую себя старым... Народ уже забыл что такое Delphi...
А ведь когда-то именно для паскаля появилась самая крутая IDE. Можно сказать первая IDE в современном понимании (VB не считается). И именно на паскале проще всего было писать оконные приложения под винду...
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[4]: Чем плох Паскаль?
От: ksandro Россия  
Дата: 14.06.19 15:59
Оценка: +1
Здравствуйте, Джеффри, Вы писали:

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

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

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

Тут стоит задуматься, что торайдиционные программы, которые мучают детей массивами, стоит как бы немного пересмотреть.
Sapienti sat!
Re: Чем плох Паскаль?
От: okon  
Дата: 14.06.19 17:18
Оценка:
C>Почему:
C>Говоря двумя словами: потому что в Паскале минимум неоднозначности синтаксиса.

Паскаль не плох, его не любят т.к. он не был программистом, и мало знают так как умер давно.
если вам кажется что я зарегистрировался ради именно этого поста то вам надо обратиться сюда http://podskazki.info/mnitelnost/
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[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[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: Чем плох Паскаль?
От: wildwind Россия  
Дата: 14.06.19 19:07
Оценка: +3
Здравствуйте, Cicero, Вы писали:

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

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

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

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

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

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

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

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

В "зарубежных курсах" Паскаль давно похоронили. В качестве первого языка чаще всего берут Питон, затем С/С++/Java.
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[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[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[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[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[5]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 15.06.19 13:44
Оценка: +6
Здравствуйте, netch80, Вы писали:


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


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


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


Какой замечательный код, который позволяет легко нарваться на неинициализированную переменную
Re[6]: Чем плох Паскаль?
От: Marty Пират  
Дата: 15.06.19 21:34
Оценка:
Здравствуйте, T4r4sB, Вы писали:


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

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

Да, я когда учился писать, не знал, что в тогдашних сях можно объявлять можно было объявлять переменные в любых {}, а не только в начале функции. И когда функции по сто раз переписывались, то куча переменных в начале распухала что ппц. А разбираться, что оставить, что нет, было неохота. Ну и с паскалем та же проблема была
Re[4]: Чем плох Паскаль?
От: qwertyuiop Российская Империя  
Дата: 16.06.19 06:19
Оценка:
Здравствуйте, netch80, Вы писали:

N>Ну для обучения ещё неизвестно, что лучше.

N>Циклы в сишном стиле — тут надо зазубрить идиомы, что переменная итератора всегда одна и та же (а иначе будет долго втыкать, что не так в каком-нибудь for (i = 0; ii < 100; ++i)), или, если это нарушается, нужно смотреть внимательнее, что происходит.

Если это нарушается, то компилятор об этом скажет. Но зато Си позволяет вообще не привязываться к переменной цикла, а проверять условие выхода другими способами, которые лишь косвенно связаны с переменной цикла.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
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[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[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[8]: Чем плох Паскаль?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.06.19 13:48
Оценка: -1
Здравствуйте, Sharowarsheg, Вы писали:


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


Ну в итоге то вся работа будет связана именно с обработкой данных. И нужно не только жуков на иголки насаживать.
Программирование это инструмент. Например нельзя изучать физику без высшей математики. Ибо зазубривая формулы не зная откуда они берутся, тоже отбивает всю охоту.
А вот зная постановку задачи и её решение все становится значительно проще.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 16.06.2019 17:37 Serginio1 . Предыдущая версия .
Re[4]: Чем плох Паскаль?
От: Pzz Россия http://pzz.livejournal.com/
Дата: 16.06.19 15:01
Оценка:
Здравствуйте, MamutArGud, Вы писали:

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


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


MAG>В каком месте Swift динамически типизиурем?


"что-то типа Питона"
Re: Чем плох Паскаль?
От: scf  
Дата: 16.06.19 15:05
Оценка: +1
Здравствуйте, Cicero, Вы писали:

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

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

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


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

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

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

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

И о минусах:

25х80, текстовый интерфейс и запуск через dosbox — некруто.
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[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[9]: Чем плох Паскаль?
От: Ops Россия  
Дата: 16.06.19 17:28
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

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


Это куда проще многих других школьных концепций. Может производные тоже выкинуть из школьной программы?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[10]: Чем плох Паскаль?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.06.19 17:36
Оценка:
Здравствуйте, pagid, Вы писали:

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


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

P>Значит школьники зря математику на уроках учат. Им бы сначала высшую преподнести, тогда можно и школьной заниматься. Или ты что-то другое называешь изучением, а может быть и математикой
Спасибо. Поправлю. Хотел написать "нельзя изучать физику без высшей математики"
и солнце б утром не вставало, когда бы не было меня
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[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[3]: Чем плох Паскаль?
От: borga  
Дата: 15.06.19 21:29
Оценка:
Здравствуйте, netch80, Вы писали:

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


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


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

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

N>Да, там другие грабли, и я их описал
Автор: netch80
Дата: 13.06 22:26
.


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

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

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

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

Это все глупости я даже не буду опровергать.
Человек вполне конкретно расписал вот тут
Автор: scf
Дата: 16.06 18:05
: вникайте до просветления!
Re[2]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 15.06.19 21:29
Оценка:
Здравствуйте, scf, Вы писали:

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

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

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


Я буду. Списки выбросить вместе с указателями. Можно и массивы тоже выбросить. Заодно и графики трёхмерных функций, всё равно стереометрия где-то в самом конце последнего класса, если я правильно помню, а к этому времени все уже определятся, будут они поступать на информатику или нет. Те, кто будут, тем факультатив, а остальные пусть хоть стереометрию осилят.
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 14:32


В Ц/Ц++ то же самое — в 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 03:56
Оценка: +2
Здравствуйте, kov_serg, Вы писали:

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

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

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

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


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


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

А если тип должен определять, какой из перегруженных вариантов функции должен вызваться?
Re[10]: Чем плох Паскаль?
От: AlexRK  
Дата: 16.06.19 03:59
Оценка: -1
Здравствуйте, netch80, Вы писали:

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

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

Вопрос не ко мне, но очевидно же, что compile error.
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 18:05
: вникайте до просветления!


А, то есть тоже аргументов у вас нет, а есть религия.
Спасибо, вопросов нет.
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[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[4]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 16.06.19 06:41
Оценка: +1
Здравствуйте, Mr.Delphist, Вы писали:

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

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

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

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

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

C>А зачем?

А зачем в школе предмет — информатика? Может и не нужен но если нужен, то как минимум про байты с битами придется рассказать, про организацию памяти, в простейшем виде, с линейной адресацией наверно тоже. Можно конечно предполагать, что библиотекарше и секретарше достаточно будет знать почти человеческий SQL Excel Питон. Но он точно школьку нужен больше, чем байт с битом?
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[7]: Чем плох Паскаль?
От: Александр Кузнецов Россия  
Дата: 16.06.19 17:35
Оценка:
Здравствуйте, netch80, Вы писали:

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


N>- а условия i <= 9 и i < 10 это одно и то же? (в спокойной обстановке они сами это скажут и посмеются, что кто-то не понимает, но когда сам начинаешь писать, нервы всё сбивают)


от 0 до 9 — это включая 9, или нет? ) Самое смешное, что семантически "до" допускает гораздо более неоднозначную трактовку, чем <, или <=. И как раз в Паскале это надо "просто запомнить", так как понять невозможно.

На самом деле в любом языке есть куча вещей, которые понять либо невозможно и надо тупо запоминать, либо можно, но только уже постигнув дзен этого языка. Но проблема в том, что сейчас подавляющее большинство языков С-подобные. Т.е. абстрактному студенту сперва надо запомнить специфику синтаксиса одного языка, а потом оперативно переключаться на другой. И выбор, к сожалению, не выглядит как: "учить на Паскале", или "учить на С-подобном языке". Он выглядит так: "Учить на С-подобном языке сразу" или "Учить на Паскале, а потом тут же переучивать на С-подобное".
Да, глупо отрицать, что Паскаль лучше подходит для обучения (он, в конце концов, для этого и задумывался). Проблема в том, что пара-тройка проблемных мест С-подобного синтаксиса, с которыми может столкнуться новичок, не перекрывают необходимости учить заново новый язык, практически полностью пуская на свалку знания по старому.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
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[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[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]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 18.06.19 10:37
Оценка:
Здравствуйте, pagid, Вы писали:

N>>Я ж говорил — у Borland многие ограничения уже ослаблены.

P>Вложенные процедуры/функции были в языке изначально.
N>>Вроде можно. Но это тот же самый костыль.
P>Почему костыль? Напротив — модная возможность возвращать несколько значений это синтаксический сахар.

Сейчас это не возврат нескольких значений, это возврат структуры из нескольких полей как одного значения.
Костыльность на нескольких уровнях:

— ABI: большинство современных соглашений по вызову предусматривают несколько аргументов (первые — в регистрах, дальше — на стеке), но только одно возвращаемое значение (с поправкой на спецслучаи типа "complex — возвращаем в xmm0 и xmm1"). Например, тут. Дополнительная передача через стек => затраты на запись и чтение, хотя можно было бы для входных параметров и результатов выделить один и тот же набор регистров. Зачем их разделять? Например, для x86-64 SysV — входы в rdi, rsi, rdx, rcx, r8, r9, результат в rax. А нормально было бы — те же 7 регистров и на входе, и на выходе.

Это как раз пример, что ещё недавно из-за замшелой мысленной традиции никто не думал про возврат нескольких значений (фактически, это только сейчас взломано и начинают думать, как это решать).

— Для языков типа C++ может возникнуть проблема цены и принципиальной возможности дополнительного перемещения значения (сначала в структуру возврата, потом из неё в целевую переменную).
Сейчас есть штатная экономия такого рода (начиная с C++11): если функция объявляет тип возврата string (например; вообще любой тип годится), локально результат кладётся тоже в string и он возвращается, компилятор может сэкономить на одном копировании или даже двух, просто передав адрес целевой строки. Возврат структуры — мешает этому.
Re[9]: Чем плох Паскаль?
От: AlexRK  
Дата: 18.06.19 10:39
Оценка:
Здравствуйте, netch80, Вы писали:

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

N>А чем он так мешает? Ну, присвоить результат нельзя. Так и при не-void его присваивать необязательно.

Речь не о том, мешает или не мешает, а о том, что функции делятся на два мира — нельзя использовать void в обобщенном коде. Приводил же пример выше на псевдокоде. Де-факто void-функции — это ровно то же самое, что и в паскале "procedure".

N>>>2. Если уже говорить про подобные возможности, то надо вспоминать и возврат не одного значения из функции, а многих. В C++, считаем, есть (хоть и криво — ни один ABI это ещё не позволяет напрямую; std::pair, std::tuple приводят к возврату структуры через скрытый параметр — указатель), и можно использовать (да хоть монады на нём строить). В Паскале нет и не ожидается.

ARK>>Я не большой знаток C++ , но не помню, что в нем это "есть". Чтобы использовать пары и туплы для комбинирования, надо, чтобы их не только возвращали, но и принимали входными параметрами, разве нет? Или можно НАПРЯМУЮ сунуть тупл (2, "test") в функцию "void Func(int a, string b)", т.е. вызвать как "Func(myTuple);"?

N>Можно.


Не конпелируется что-то: https://ideone.com/Q3TtwD

#include <iostream>
using namespace std;

void Func(int a, std::string b)
{
    std::cout << a;
    std::cout << b;
}

int main() {
    Func(33, "test");    // работает
    
    std::pair <int,std::string> myPair (33, "test");
    Func(myPair);        // не компилируется
    
    return 0;
}


prog.cpp:14:13: error: cannot convert ‘std::pair<int, std::__cxx11::basic_string<char> >’ to ‘int’ for argument ‘1’ to ‘void Func(int, std::__cxx11::string)’
Func(myPair);
^


Что я делаю не так? Или всё же не можно?

N>Даже в штатной библиотеке какой-нибудь std::map::insert принимает std::pair<> как аргумент.


Это и в паскале можно.
Re[15]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 18.06.19 10:40
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

S>>>>>Хештаблицы и прочие структуры данных сложнее, чем переменная в смысле integer или double.

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

И я про них же говорил.

N>>DB-like операции "посмотреть/уточнить параметры пациента".

N>>Управление операциями типа "если появится кровь вот в этом сегменте изображения, подать тревогу" — и таких сегментов обычно несколько, и их желательно называть.
S>У них несколько другие операции. Типа, удаление аппендикса или вроде того. Компьютер ими не управляет. В качестве интерфейса к компьютеру там вообще часто используют медсестру вместо клавиатуры.

"Вы или трусы наденьте, или крестик снимите"
Так они хоть трёхстрочные скрипты пишут? Если нет — вообще не надо было про них разговор заводить.
Если да — им нужно понимать, что такое, например, a.b, где a — некая сущность объектного характера.

N>>>>>>А это и не обязательно на таком уровне давать. Достаточно принципа "вот ключи, а вот значения при них".

S>>>>>Так же не будет. Обязательно потащится всякая алгоритмическая сложность и прочее.
N>>>>Почему? Это как раз можно на базовом уровне не вспоминать. Только на первом из продвинутых.
S>>>Нет. Не верю я в то, что это остановится на каких-то разумных пределах.
N>>Оно всегда останавливается, и сильно раньше разумных пределов.
S>Мне казалось и когда я учился, и сейчас, что сильно позже, и что сильно не хватает факультативности всякой.

Ученику всегда так кажется — "накойхер это учить?"
Только педагог с опытом знает, как именно это обучение окупается (если не идёт явным насилием).
Re[5]: Чем плох Паскаль?
От: Mr.Delphist  
Дата: 18.06.19 11:12
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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

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

Давайте по порядку:

1) Для новичка эти идеи типа "один вход — один выход" очень даже полезные. Давайте откровенно: какое качество кода будет у новичка на C, даже если без плюсов? Про сишную верёвку, стреляющую в ногу, придумали не паскалисты.
2) Указатели в Паскале есть с древнейших времён — все эти одно-много-связные списки-деревья-кольцевые-буферы-что-там-ещё пишутся студентами в больших количествах.
3) Векторы, хэширование и хэш-карты, равно как и упомянутые выше списки-деревья-буферы — у меня лично в программе обучения было. Аналогично — ООП. Собственно, это есть в любой фундаментальной книге по любому языку программирования.
4) Управление зависимостями — это настолько выше уровнем (читай — не для новичков), и настолько ортогонально к языку, что Паскаль тут не при чём
Re[4]: Чем плох Паскаль?
От: MamutArGud  
Дата: 18.06.19 11:52
Оценка:
C>>А зачем?
P>А зачем в школе предмет — информатика? Может и не нужен

В том виде, в каком есть, не нужен.

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


Нахера вот это все нужно знать школьнику? Почему никого не удивляет, что школьникам дают арифметику и алгебру, а не матанализ и теорию чисел. Но как только речь заходит о программировании, нет, подавайте в школе организацию памяти.
Re[5]: Чем плох Паскаль?
От: pagid Россия  
Дата: 18.06.19 12:09
Оценка:
Здравствуйте, MamutArGud, Вы писали:

MAG>В том виде, в каком есть, не нужен.

А в каком виде нужен?


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

Так это как раз и есть арифметика, а не матанализ.
Re[16]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 18.06.19 12:39
Оценка:
Здравствуйте, netch80, Вы писали:


N>>>DB-like операции "посмотреть/уточнить параметры пациента".

N>>>Управление операциями типа "если появится кровь вот в этом сегменте изображения, подать тревогу" — и таких сегментов обычно несколько, и их желательно называть.
S>>У них несколько другие операции. Типа, удаление аппендикса или вроде того. Компьютер ими не управляет. В качестве интерфейса к компьютеру там вообще часто используют медсестру вместо клавиатуры.

N>"Вы или трусы наденьте, или крестик снимите"

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

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

S>>Мне казалось и когда я учился, и сейчас, что сильно позже, и что сильно не хватает факультативности всякой.


N>Ученику всегда так кажется — "накойхер это учить?"

N>Только педагог с опытом знает, как именно это обучение окупается (если не идёт явным насилием).

Нет, это не правда. Через много лет после обучения я знаю, что и где окупилось, а что нет, а что и не могло окупиться. Это не слишком сложно, чтобы нужно было иметь диплом педагогического университета, чтобы понять это.
Отредактировано 18.06.2019 12:39 Sharowarsheg . Предыдущая версия .
Re[17]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 18.06.19 14:06
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

N>>"Вы или трусы наденьте, или крестик снимите"

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

S>Нет. Они не пишут скриптов. Никаких и никогда. Они пишут в ворде по шаблонам, а иногда в экселе, если в диссертацию надо.

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

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

S>>>Мне казалось и когда я учился, и сейчас, что сильно позже, и что сильно не хватает факультативности всякой.


N>>Ученику всегда так кажется — "накойхер это учить?"

N>>Только педагог с опытом знает, как именно это обучение окупается (если не идёт явным насилием).
S>Нет, это не правда. Через много лет после обучения я знаю, что и где окупилось, а что нет, а что и не могло окупиться.

Что окупилось, а что нет — да, знаете.
Что не могло окупиться, если это не предмет "программа КПСС и решения XXVII съезда" — нет.

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


Именно, что кто не профессионал в педагогике, чаще всего не понимает принципов.
Re[9]: Чем плох Паскаль?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 18.06.19 14:37
Оценка:
Здравствуйте, pagid, Вы писали:

P>Дело скорее не в однопроходности самой по себе, а в том, что в Паскале есть вложенные функции, и объявление переменных после них приведет не только к необходимости не однопроходного компилятора, но и логичным вопросам "что за ... ?"

Полностью ортогональные штуки.
Можно запросто починить синтаксис Паскаля, разрешив в любом месте писать так:
a:int := 0;

procedure IncA
begin
  a:= a + 1;
end;

Это не сломает ровным счётом ничего, кроме однопроходности компилятора.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[3]: Чем плох Паскаль?
От: Mr.Delphist  
Дата: 18.06.19 15:44
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

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

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

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

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

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

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

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


А в Delphi и того больше, можно чётко указать, где два типа — синонимы, а где — действительно неприсваиваемые друг другу, несмотря на побитовую идентичность в бинарном представлении.
Re[6]: Чем плох Паскаль?
От: MamutArGud  
Дата: 18.06.19 17:30
Оценка:
MAG>>В том виде, в каком есть, не нужен.
P>А в каком виде нужен?

Вообще нужно не программирование (или не только программирование), но и основы безопасности в сети.

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

P>Так это как раз и есть арифметика, а не матанализ.

С чего это вдруг?
Re[6]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 18.06.19 18:13
Оценка: +1
Здравствуйте, pagid, Вы писали:

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

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

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

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

MD>Давайте по порядку:
MD>1) Для новичка эти идеи типа "один вход — один выход" очень даже полезные.
Ничем оно не полезное, вообще.

MD>Давайте откровенно: какое качество кода будет у новичка на C, даже если без плюсов? Про сишную верёвку, стреляющую в ногу, придумали не паскалисты.

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

MD>2) Указатели в Паскале есть с древнейших времён — все эти одно-много-связные списки-деревья-кольцевые-буферы-что-там-ещё пишутся студентами в больших количествах.

Угу, причём без всякого понимания того, что они таки пишут. Если речь идёт о реальном программировании, то отсутствие generic'ов убивает все эти дервья и списки.

MD>3) Векторы, хэширование и хэш-карты, равно как и упомянутые выше списки-деревья-буферы — у меня лично в программе обучения было. Аналогично — ООП. Собственно, это есть в любой фундаментальной книге по любому языку программирования.

Нету generic'ов.

MD>4) Управление зависимостями — это настолько выше уровнем (читай — не для новичков), и настолько ортогонально к языку, что Паскаль тут не при чём

Во всех современных языках управление зависимостями, если не в самом языке, то в стандартной библиотеке.
Sapienti sat!
Re[7]: Чем плох Паскаль?
От: AlexRK  
Дата: 18.06.19 18:29
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>Ничем оно не полезное, вообще.

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

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


Total Commander!

C>Угу, причём без всякого понимания того, что они таки пишут. Если речь идёт о реальном программировании, то отсутствие generic'ов убивает все эти дервья и списки.

C>Нету generic'ов.

А что насчет Golang? В нем отсутствие генериков не является препятствием реальному программированию? Но зато в паскале отсутствие генериков сразу ставит крест на обучении. Верно?
Отредактировано 18.06.2019 18:29 AlexRK . Предыдущая версия .
Re[8]: Чем плох Паскаль?
От: MamutArGud  
Дата: 18.06.19 18:40
Оценка:
ARK>Почему же, один выход проще, чем несколько. Вообще, ретурны, рассеянные где попало в теле функции — это нехорошо. Мешает рассуждениям о программе

Наоборот, помогает

ARK> часто является признаком говнокода.


Нет, не часто

C>>Угу, причём без всякого понимания того, что они таки пишут. Если речь идёт о реальном программировании, то отсутствие generic'ов убивает все эти дервья и списки.

C>>Нету generic'ов.

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


В Golang во-первых, есть множество вещей, которых в Паскале нет. Во-вторых, отсутсвие generic'ов таки мешает.
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[5]: Чем плох Паскаль?
От: AlexRK  
Дата: 18.06.19 19:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

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

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

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

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

Почему в паскале типизация не строгая, а в Go и Rust — строгая?
Re[5]: Чем плох Паскаль?
От: SergeyIT Россия  
Дата: 18.06.19 21:12
Оценка:
Здравствуйте, Cyberax, Вы писали:

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>>

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

Придет какой-нибудь новатор и поправит, например
var b: array[1..9] of integer;
И что будет, без этой строгости?
Re[6]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 19.06.19 03:26
Оценка:
Здравствуйте, SergeyIT, Вы писали:

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>>>

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

SIT>Придет какой-нибудь новатор и поправит, например

SIT>var b: array[1..9] of integer;
SIT>И что будет, без этой строгости?

Массивы будут неидентичны, и поэтому и присвоение не пройдёт.
Re[10]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 19.06.19 04:33
Оценка:
Здравствуйте, AlexRK, Вы писали:

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

N>>А чем он так мешает? Ну, присвоить результат нельзя. Так и при не-void его присваивать необязательно.
ARK>Речь не о том, мешает или не мешает, а о том, что функции делятся на два мира — нельзя использовать void в обобщенном коде.

Ну это только потому, что никто не хотел доработать C++ в эту сторону. Хотели бы — придумали, обёрток такого рода начиная с C++11 "вагон и маленькая тележка".

ARK>>>Я не большой знаток C++ , но не помню, что в нем это "есть". Чтобы использовать пары и туплы для комбинирования, надо, чтобы их не только возвращали, но и принимали входными параметрами, разве нет? Или можно НАПРЯМУЮ сунуть тупл (2, "test") в функцию "void Func(int a, string b)", т.е. вызвать как "Func(myTuple);"?


N>>Можно.


ARK>Не конпелируется что-то: https://ideone.com/Q3TtwD


А, я криво прочитал. Напрямую не получится, нужно, чтобы и аргумент был tuple<>.
Но косвенно такое построить можно, на variadic templates. std::function, например, оборачивает лямбды как раз через такие фокусы.

N>>Даже в штатной библиотеке какой-нибудь std::map::insert принимает std::pair<> как аргумент.

ARK>Это и в паскале можно.

Структурой? Слишком банально.
Re[11]: Чем плох Паскаль?
От: pagid Россия  
Дата: 19.06.19 05:29
Оценка:
Здравствуйте, netch80, Вы писали:

N>- ABI: большинство современных соглашений по вызову предусматривают несколько аргументов (первые — в регистрах, дальше — на стеке), но только одно возвращаемое значение (с поправкой на спецслучаи типа "complex — возвращаем в xmm0 и xmm1"). Например, тут. Дополнительная передача через стек => затраты на запись и чтение, хотя можно было бы для входных параметров и результатов выделить один и тот же набор регистров. Зачем их разделять? Например, для x86-64 SysV — входы в rdi, rsi, rdx, rcx, r8, r9, результат в rax. А нормально было бы — те же 7 регистров и на входе, и на выходе.

И какие предложения? В связи с обсуждаемым разработать новые ABI и срочно их внедрить?

N>Это как раз пример, что ещё недавно из-за замшелой мысленной традиции никто не думал про возврат нескольких значений (фактически, это только сейчас взломано и начинают думать, как это решать).

А точно возврат нескольких значений это настолько революционно, а главное необходимо? Единственное место (из тех, что трогал), где не обойти это Go, но там специфические соглашения об обработке ошибок и оно понапихано в каждой строчке.

N>- Для языков типа C++ может возникнуть проблема цены и принципиальной возможности дополнительного перемещения значения (сначала в структуру возврата, потом из неё в целевую переменную).

N>Сейчас есть штатная экономия такого рода (начиная с C++11): если функция объявляет тип возврата string (например; вообще любой тип годится), локально результат кладётся тоже в string и он возвращается, компилятор может сэкономить на одном копировании или даже двух, просто передав адрес целевой строки. Возврат структуры — мешает этому.
Получается, что кругом они проблемы.
Re[7]: Чем плох Паскаль?
От: pagid Россия  
Дата: 19.06.19 05:37
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

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

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

Так можно все, что угодно пропустить, но мы возвращаемся к исходному, для чего этот предмет и что там нужно изучать
Re[12]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 19.06.19 07:30
Оценка:
Здравствуйте, pagid, Вы писали:

N>>- ABI: большинство современных соглашений по вызову предусматривают несколько аргументов (первые — в регистрах, дальше — на стеке), но только одно возвращаемое значение (с поправкой на спецслучаи типа "complex — возвращаем в xmm0 и xmm1"). Например, тут. Дополнительная передача через стек => затраты на запись и чтение, хотя можно было бы для входных параметров и результатов выделить один и тот же набор регистров. Зачем их разделять? Например, для x86-64 SysV — входы в rdi, rsi, rdx, rcx, r8, r9, результат в rax. А нормально было бы — те же 7 регистров и на входе, и на выходе.

P>И какие предложения? В связи с обсуждаемым разработать новые ABI и срочно их внедрить?

Да. С учётом того, что "срочно" в данной области это 10-15 лет.

N>>Это как раз пример, что ещё недавно из-за замшелой мысленной традиции никто не думал про возврат нескольких значений (фактически, это только сейчас взломано и начинают думать, как это решать).

P>А точно возврат нескольких значений это настолько революционно, а главное необходимо? Единственное место (из тех, что трогал), где не обойти это Go, но там специфические соглашения об обработке ошибок и оно понапихано в каждой строчке.

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

Например, берём Unix API:
int open(аргументы);
реально два значения — дескриптор и код ошибки (который поступает в errno).
В Rust, Erlang и аналогах это честно передают как {ok, Value} | {error, Error}.
int pipe(int fildes[2]);
три значения — два дескриптора и код ошибки.
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
три выходных — код ошибки, сокет и адрес.
И так далее.
Windows? То же самое: у до чёрта функций код ошибки передаётся боковым каналом, его надо доставать через GetLastError(). И аналог такого accept() есть, и многое другое.
Просто C API без учёта ОС — те же пляски с errno на стандартной библиотеке (да хоть strtol); div(), возвращающая структуру.

Да, похоже на то, как Go возвращает ошибки. Но это потому, что они возвращаются явно, в то время как в C их скрывают. А зачем скрывать? Явно — выгоднее и полезнее.

Кстати, именно Go это при текущем ABI всё равно не помогает: почему-то у них до сих пор передачи через регистр нет в принципе. И аргументы, и возвращаемые значения — все на стеке.

N>>- Для языков типа C++ может возникнуть проблема цены и принципиальной возможности дополнительного перемещения значения (сначала в структуру возврата, потом из неё в целевую переменную).

N>>Сейчас есть штатная экономия такого рода (начиная с C++11): если функция объявляет тип возврата string (например; вообще любой тип годится), локально результат кладётся тоже в string и он возвращается, компилятор может сэкономить на одном копировании или даже двух, просто передав адрес целевой строки. Возврат структуры — мешает этому.
P>Получается, что кругом они проблемы.

По отношению к чему?
Re[6]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 19.06.19 08:09
Оценка:
Здравствуйте, SergeyIT, Вы писали:

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

SIT>Придет какой-нибудь новатор и поправит, например
SIT>var b: array[1..9] of integer;
SIT>И что будет, без этой строгости?
Ну вот когда поправит — тогда и выдавать ошибку компиляции.
Sapienti sat!
Re[8]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 19.06.19 08:14
Оценка: +2
Здравствуйте, pagid, Вы писали:

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

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

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

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

Я знаю людей (не программистов), которые ничерта не понимают в основах программирования, но пишут вполне неплохие скрипты на Питоне или Matlab. Так что я не вижу никаких проблем в том, что будет больше упор на практические стороны.
Sapienti sat!
Re[6]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 19.06.19 08:25
Оценка:
Здравствуйте, AlexRK, Вы писали:

C>>Go, Rust, даже JavaScript.

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

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

C>>Из современных — Go, Rust, Elm.
ARK>Почему в паскале типизация не строгая, а в Go и Rust — строгая?
Ну начнём с того, что в Паскале в принципе нет generic'ов. Т.е. реальный код не сможет использовать обобщённые алгоритмы и контейнеры.

Но даже если на это закрыть глаза, то в стандартном Паскале нет проверки численных переполнений, хотя есть ограниченные типы. В некоторых реализациях эти проверки таки добавили.
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]: Чем плох Паскаль?
От: pagid Россия  
Дата: 19.06.19 09:37
Оценка:
Здравствуйте, AlexRK, Вы писали:

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

В школе используют почти первоначальное подмножество. Разумеется на нем ничего "промышленного" не написать, и даже вряд ли можно написать что-то полезное выходящее за пределы учебных целей.
Re[7]: Чем плох Паскаль?
От: pagid Россия  
Дата: 19.06.19 09:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

Скорее всего оно просто не определяется как часть языка и в языке не предусмотрена возможность обработки этой ситуации.
Re[9]: Чем плох Паскаль?
От: pagid Россия  
Дата: 19.06.19 09:54
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну да, рассказать можно и даже нужно, в качестве заметки на полурока. Заниматься разборами представления чисел в памяти — в базовом курсе не нужно.

А в углубленном?
Ну или вот такое дело, в курсе информатики весьма подробно рассматривается представление чисел в разных системах счисления, когда в двоичной или шестнадцатеричной это уже представление в памяти? или представление в памяти это рассмотрение представления чисел с плавающей точкой в соответствии с IEEE 754 с учетом всяких там правил нормализации и тому подобного? Это точно не нужно, а вот показать, что разрядность и точность для дробных в машинном представлении ограничена полезно или даже необходимо.

C>Есть мнение, что так и надо делать.

Как?

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


То есть на уроках информатики должны учить писать скрипты на Питоне, Matlab и наверно пользоваться Excel'ем?
Ну может и так Хотя Питон в такой раскладке я бы из списка выбросил, Excel там чуток и так изучают, что там с Matlab и нужен ли он не знаю.
Re[7]: Чем плох Паскаль?
От: Mr.Delphist  
Дата: 19.06.19 09:58
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нету generic'ов.


Это да, согласен.

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


Имя, сестра! Имя! (ц)

Как именно управляется зависимость в C++ STL? Как это делается в дотнетах? (устану перечислять количество либ для этого, и все нестандартные). Тогда, может быть, Джа? Наверняка в Весенней куче пара-тройка кунштюков для этого — осталось лишь назначить какой-то из них стандартынм
Re[5]: Чем плох Паскаль?
От: Mr.Delphist  
Дата: 19.06.19 10:46
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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

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

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

C>Из современных — Go, Rust, Elm.


Go — основан на duck-typing (ещё бы, наследования-то не завезли), и это Строгая Типизация? Лол, рофл, что там далее по списку.
Rust — очень академичный язык, и, как бы смешно ни звучало, у меня он ассоциируется с ролью "Паскаля нашего времени". Пока что Rust оправдывает это ожидание, болтаясь где-то около нуля на индустриальной шкале.
E... простите, ЧТО? А, гугл подсказывает, что это препроцессор для JS, который используют все три компании, которые про него слышали. Потрясающий production!

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


Похоже, насчёт строгой типизации нам говорить ещё рано
Re[4]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 19.06.19 11:06
Оценка: +2
Здравствуйте, pagid, Вы писали:

C>>А зачем?

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

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

И еще показать к чему приводит использование компьютеров, когда не понимаешь что хочешь.
и показать весь этот бл%^&кий цирк каменный век по подготовке к работе с нашими гос услугами личными, кабинетами, цифровыми подписями и криптопровайдерами
Re[6]: Чем плох Паскаль?
От: Mr.Delphist  
Дата: 19.06.19 15:03
Оценка:
Здравствуйте, pagid, Вы писали:

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


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

P>Так это как раз и есть арифметика, а не матанализ.

Арифметикой это кажется, пока знаешь только один способ организации памяти. Что делать — разбаловала нас линейная адресация.
Re: Чем плох Паскаль?
От: _hum_ Беларусь  
Дата: 19.06.19 15:10
Оценка:
Здравствуйте, Cicero, Вы писали:

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

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

Тоже в свое время думал, на чем преподавать информатику (1 курс) тех.вуза. Остановился на PascalABC.Net.
Достоинства:
— максимально нацелен на то, чтобы обучаемый понял базовые концепты классического императивного программирования, не отвлекаясь на всякие-разные технические детали;
— разработчики постарались внести новшества, позволяющие приблизить его к современным языкам (например, переменные можно определять в теле программы, есть автовывод типов, анонимные функции, динамические массивы и т.п.);
— минималистическая IDE, содержащая все что нужно для знакомства с базовыми концептами работы с IDE (текстовый редактор с автоформатером и интелисенс, инструменты отладки, запуска).


Недостатки:
— остались атавизмы вроде "константы определяются только за пределами тела программы";
— наверное, из-за того, что язык построен на базе платформы .net, и авторы старались использовать ее возможности, появилась некоторая мешанина, не всегда дающая последовательно излагать материал. Например, из языка убрали возможность выделения массива заданного размера в динамической памяти, видимо, посчитав, что это не нужно, потому как есть заимствованный тип данных "динамический массив". Но, как по мне, это неправильно, потому как обучающийся не сможет полностью понять внутреннюю логику работы такого динамического массива без понимания того, что такое массив в динамической памяти, что такое ссылка/указатель, что такое класс/объект. Есть и другие вылезающие моменты технического характера (типа, статические массивы являются обычными типами, а динамические — ссылочными; статические массивы не могут передаваться в функцию через параметр без предварительного объявления типа-алиаза для этого параметра, а динамические можно, и т.п.);
— проблема с программированием GUI; вроде, какие-то попытки дать возможность в языке попробовать и это писать, но выглядят слишком коряво;
— осталась многословность Паскаля (эти begin end в более-менее нетривиальной программе выглядит чудовищно).
Re[7]: Чем плох Паскаль?