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

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

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

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

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

C>Почему:

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

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

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


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



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

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

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

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

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


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

Из плюсов:

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

Из минусов:

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

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

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

Хватит. Язык был неплох для обучения в 80-х годах. Какая то применимость была в 90-е. Уже в двухтысячном от него нужно было держаться как можно дальше, появились языки много лучше. В 2019-м даже мысли не может быть такое использовать для обучения. Еще б бейсик ранних 80-х бы вспомнили, с переменными f1 и строковыми вида $b5, с ограничениями на максимальную длину переменной, с редакторированием по строчкам, со всякими rename, gosub, goto . После таких ужасов прямой путь на ассемблер, чтоб на ассемблере не казалось все так страшно. Вот только ниша ассемблера в современном мире весьма узка, и начинать с него нет никакой необходимости.
Re: Чем плох Паскаль?
От: 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
Оценка: 4 (3) +6
Здравствуйте, Cicero, Вы писали:

C>Почему:

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

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

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

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

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

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

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

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

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

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

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


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

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

Вирт, кстати, часть этих огрехов Pascal исправил, создав Modula. Но упёртым баранам из всяких Borland было на это плевать.
The God is real, unless declared integer.
Re[2]: Чем плох Паскаль?
От: Слава  
Дата: 13.06.19 19:32
Оценка: :)
Здравствуйте, netch80, Вы писали:

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


Вы забыли ещё про синтаксический оверхед написать.
Re: Чем плох Паскаль?
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 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, то опять таки я за принципиальное разделение двух видов деления на уровне синтаксиса.

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

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


Мне кажется, использование в качестве первого языка, языка с динамической типизацией, уродует головной мозг человека навсегда.
Re[2]: Чем плох Паскаль?
От: Pzz Россия https://github.com/alexpevzner
Дата: 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 или с десктопными ява-приложениями.
Re[3]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 13.06.19 22:58
Оценка: +3
Здравствуйте, 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>В обсуждаемом не должно быть цели "после к станку". Даже в ВУЗе при начальном обучении программированию не должно быть такой цели.

Во-первых, должна быть. Учат чему-то полезному, и конкретный язык здесь, хоть и не первоочередная составляющая, но важная. А если ещё при обучении человек сразу включается в реальную работу и видит полезный выхлоп от своей работы — то это ещё больше работает на качество обучения.
Во-вторых, тем более не должно быть цели учить тому, после чего надо заново переучиваться.
The God is real, unless declared integer.
Отредактировано 14.06.2019 5:09 netch80 . Предыдущая версия .
Re[3]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 04:51
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

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


Именно поэтому Паскаль не подходит.
The God is real, unless declared integer.
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>Но после перехода на С всё стало абсолютно кристально понятно сразу же.


Ну это ты зря. Как раз с синтаксисом указателей у Паскаля лучше.
The God is real, unless declared integer.
Re[3]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 05:07
Оценка:
Здравствуйте, Pzz, Вы писали:

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


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

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


См. выше.
Да, после Вирта вроде никто такое не повторял (ну, Ruby позаимствовал, один на десятки новых языков).
The God is real, unless declared integer.
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 клиента, не к ночи будь сказано).
The God is real, unless declared integer.
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-указатель (хоть он так и не назывался).
The God is real, unless declared integer.
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
Оценка: +4
Здравствуйте, kov_serg, Вы писали:

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

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

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

Да любой современный язык — по умолчанию не переменная (var), а val, которой не изменить значение после присваивания. Надеюсь до чистой Java такое вскоре тоже дойдет, это как раз то, что можно исправить, хоть и не полностью. Даже такой капец, как JavaScript — там именно с фичами то не так и плохо, там в другом проблема.
Re: Чем плох Паскаль?
От: Александр Кузнецов Россия  
Дата: 14.06.19 08:47
Оценка: 6 (1) +1
Здравствуйте, Cicero, Вы писали:

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

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

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

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

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

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

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

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

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

C>Почему:

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

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

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

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

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


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

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


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

Течёт вода Кубань-реки куда велят большевики.
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++ и в этом смысле ой.
The God is real, unless declared integer.
Отредактировано 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
Оценка: +1
Здравствуйте, AlexRK, Вы писали:

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

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

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

do
  x();
while(y);


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

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

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

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

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

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

Потому что приоритеты операций придуманы не от балды, а чтобы упростить наиболее типовое применение.
Если бы сложение было приоритетнее умножения, и надо было бы a+b*c писать a+(b*c), чтобы его не поняли как (a+b)*c, то аналогичные жалобы были бы и тут.
Запись типа if a=0 and b>0, понимаемая как if (a=0) and (b=0), в этом смысле полезнее в десятки раз, чем if a=(0 and b)>0, или как-то ещё не по обычным ожиданиям.
The God is real, unless declared integer.
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>В этом есть резон, но я считаю, что приоритеты вообще не нужны. Всегда явно выделяю скобками все операции.


Боюсь представить себе, как выглядит твой код и как на это ругаются коллеги.
Рекомендовать всем такое, увы, не могу.
The God is real, unless declared integer.
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.
The God is real, unless declared integer.
Отредактировано 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. Но — всё равно живой язык полезнее.
The God is real, unless declared integer.
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-стиля это само получается.
The God is real, unless declared integer.
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?
The God is real, unless declared integer.
Re[2]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 14.06.19 13:26
Оценка:
Здравствуйте, borga, Вы писали:

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


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

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

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

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

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

Да. Потому что
1) лучше, когда синтаксические средства группировки заметно выделяются формой, чем сливаются с другими словами и идентификаторы.
2) например, есть штатные средства перейти на противоположную скобку (любого вида) в каком-нибудь vim, но с begin/end это становится в разы сложнее. Учить редакторы фолдить тоже усложнение.
The God is real, unless declared integer.
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>Говоря двумя словами: потому что в Паскале минимум неоднозначности синтаксиса.

Паскаль не плох, его не любят т.к. он не был программистом, и мало знают так как умер давно.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
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 строчек помогли проекту на пару миллионов строк, морально подстёгивает профессиональный рост лучше, чем тупые отметки "отлично".
The God is real, unless declared integer.
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>Какие в школе расширенные случаи? Даже сортировка... написали один раз сортировку пузырьком, и достаточно. Больше она нигде в школьной программе не нужна, по крайней мере в той школьной программе, которой меня учили. А школьная программа, по которой меня учили, была слишком сложная и так, оттуда бы ещё половину выкинуть.


Так минимум на треть кривизна программы как раз из-за того, что рассчитывается под отсутствие стандартной библиотеки.
The God is real, unless declared integer.
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. Статьи «как всё плохо» на условном хабре.

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


Я видел больше вариантов. Кто-то привык к очень странному стилю, кто-то подтачивается под любимый фреймворк (подходы которого именно тут неуместны)...
The God is real, unless declared integer.
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; ?
The God is real, unless declared integer.
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> С точки зрения промышленного программирования с указателями в С — полная катастрофа с безопасностью, но для обучения как раз идеально.


Не-а. Чтобы понять простую идею "указатель это адрес", это всё не нужно.
Чтобы понять арифметику указателей — тоже. Её по любому надо явно объяснить, и этого достаточно.
The God is real, unless declared integer.
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 Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 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 Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 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 просто подсвечивая имя под курсором по всему тексту.
  Скрытый текст

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; внутри цикла.
The God is real, unless declared integer.
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 Россия https://github.com/alexpevzner
Дата: 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...
Но они страдают теми же системными проблемами языка.
The God is real, unless declared integer.
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 значение, но компилятор способен выкинуть начальное присвоение, если видит, что обойдётся без него.

По нормальному, да, компилятор способен отработать и вариант со всеми именами с типами вначале, и посреди кода. Но зачем дублировать?
The God is real, unless declared integer.
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.19
.


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

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

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

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

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

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

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

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


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


Ну так не поэтому ли они не получили популярности?
The God is real, unless declared integer.
Re[3]: Чем плох Паскаль?
От: elmal  
Дата: 15.06.19 22:12
Оценка:
Здравствуйте, ksandro, Вы писали:

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

В том то и дело что это было когда то . Причем очень давно. Для тех времен да, Delphi был неплохим выбором для тех, кому нужно было что то налабать, при этом не являясь профессиональным программистом. Сейчас уже даже в этой нише лучше от дельфей держаться подальше.
Re[10]: Чем плох Паскаль?
От: alpha21264 СССР  
Дата: 16.06.19 01:08
Оценка:
Здравствуйте, Ops, Вы писали:

Ops>Может производные тоже выкинуть из школьной программы?


К сожалению, уже выкинули.

Течёт вода Кубань-реки куда велят большевики.
Re[11]: Чем плох Паскаль?
От: pagid Россия  
Дата: 16.06.19 01:30
Оценка:
Здравствуйте, alpha21264, Вы писали:

A>К сожалению, уже выкинули.

Ну не знаю, что-то сомнительно.

Смотрю учебник Мордковича, вижу изучение производных в 10 классе. Смотрю учебник Никольского, вижу производные в 11 классе.
Re[3]: Чем плох Паскаль?
От: Mr.Delphist  
Дата: 16.06.19 01:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


Простите, а что за "неправильная" такая сторона у Паскаля? Я вот вообще с Бейсика начинал, много их разных у меня было (Вильнюс, Спектрум, кучка ещё всяких диалектов). Вдруг тоже что-то вправить надо — а не замечаю...

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


Но берут-то почему? Подскажу: там есть ругательные буквы БЛ..., есть кусочек ругательного слова ...ИОТ, хотя в целом само слово — хорошее
Re[2]: Чем плох Паскаль?
От: MamutArGud  
Дата: 16.06.19 01:46
Оценка:
scf>НО — для начального обучениния избыток парадигм вреден. К примеру, вот что входило в мою школьную программу:

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

scf>- процедуры, функции


Вот только за это Паскаль надо выкидывать и забывать как страшный сон. Только виртовские детища, емнип, на ровном месте создают из одной сужности (функция), две. Иди, попробуй объясни ее ... да хоть кому бы то ни было.

scf>Теперь о плюсах Паскаля:

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

Зато нужны другие вещи, которые надо только зазубрить

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

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

С этими плюсами лучше уж Erlang взять
Re[15]: Чем плох Паскаль?
От: AlexRK  
Дата: 16.06.19 03:38
Оценка:
Здравствуйте, netch80, Вы писали:

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

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

Записана, конечно — вот мое первое сообщение на эту тему: http://rsdn.org/forum/education/7470487.1
Автор: AlexRK
Дата: 14.06.19


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


Меняем "Ц/Ц++" на "C#/Java" и получаем верное утверждение. Про Ц/Ц++ я не знал (собственно, цикл do вообще никогда не использовал), но это не меняет сути — что паскаль далеко не единственный язык с таким подходом.

N>К тому, что, повторюсь, особый синтаксис тут задаётся атрибутами и ключевыми словами.

N>А в варианте Паскаля меняется сам парсер.

Может, какой-то кривой парсер, написанный непонятно кем, и меняется, но я не вижу объективных причин для этого. Терминатором функции или программы служит end, а не последующий символ.

N>Что будет, если сделать комментарии после этой точки? Всё сломается или проигнорирует?


Где именно — в классическом паскале? Не знаю. Скорее всего, второе.

N>Зачем она нужна тогда? Есть EOF уровня файла. Есть блок begin-end вне пределов любых функций.

N>Если второе, то зачем эта точка вообще была нужна?

Для строгости и лучшей читаемости кода, я так полагаю. Вот начало, вот конец.

Можно и без точки обойтись. Можно без точек с запятой после каждой строки. Можно без блоков begin/end или {}. Это всё вопрос вкуса. Вирт сделал язык строгим в такой степени, в какой посчитал нужным.

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

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

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

ARK>>x = a + (b * c);

ARK>>Сразу беглым взглядом четко видно структуру выражения.
N>Ню ню. Не уверен, что любая команда поддержит такое. Скорее — наоборот.

Вполне возможно. А может и нет. Такие утверждения лучше обосновывать — скажем, цитатами из Code Style известных проектов.

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

ARK>>Кстати, многие языки и вовсе не имеют приоритета операторов — smalltalk, prolog, lisp, pony, наверняка еще кучу забыл.

N>Ну так не поэтому ли они не получили популярности?

Я считаю, что это крайне маловероятно. Вопрос популярности языков вообще мало коррелирует с их особенностями, по-моему.
Re[3]: Чем плох Паскаль?
От: AlexRK  
Дата: 16.06.19 03:45
Оценка:
Здравствуйте, MamutArGud, Вы писали:

MAG>Вот только за это Паскаль надо выкидывать и забывать как страшный сон. Только виртовские детища, емнип, на ровном месте создают из одной сужности (функция), две. Иди, попробуй объясни ее ... да хоть кому бы то ни было.


Отчего ж, не только виртовские создают из одной сущности две. Страуструповские, ричекернигановские, хейлсберговские, гослинговские детища — они все тоже туда же. Иди попробуй объясни, зачем в сикраше Action и Func ... да хоть кому бы то ни было. Выкинуть и забыть этот весь шлак как страшный сон!
Отредактировано 16.06.2019 3:46 AlexRK . Предыдущая версия .
Re[9]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 03:56
Оценка: +2
Здравствуйте, kov_serg, Вы писали:

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

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

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

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


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


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

А если тип должен определять, какой из перегруженных вариантов функции должен вызваться?
The God is real, unless declared integer.
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> Все желающие узнать, что такое хештаблица, и чем отличается криптографический хеш от используемого в хештаблице, приглашаются на факультативные занятия информатикой.


А это и не обязательно на таком уровне давать. Достаточно принципа "вот ключи, а вот значения при них".
The God is real, unless declared integer.
Re[4]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 05:37
Оценка:
Здравствуйте, borga, Вы писали:

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

B>Человек вполне конкретно расписал вот тут
Автор: scf
Дата: 16.06.19
: вникайте до просветления!


А, то есть тоже аргументов у вас нет, а есть религия.
Спасибо, вопросов нет.
The God is real, unless declared integer.
Re[11]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 05:42
Оценка:
Здравствуйте, AlexRK, Вы писали:

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


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

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

ARK>Вопрос не ко мне, но очевидно же, что compile error.


То есть надо все ветки привести явно к одному типу значения (или к совместимым с минимальными различиями).
Ну вот после этого и видно, что явное задание типа целевой переменной — проще и эффективнее, как минимум в заметной части случаев.
The God is real, unless declared integer.
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>Так же не будет. Обязательно потащится всякая алгоритмическая сложность и прочее.

Почему? Это как раз можно на базовом уровне не вспоминать. Только на первом из продвинутых.
The God is real, unless declared integer.
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> Проблема в том, что пара-тройка проблемных мест С-подобного синтаксиса, с которыми может столкнуться новичок, не перекрывают необходимости учить заново новый язык, практически полностью пуская на свалку знания по старому.


Да.
The God is real, unless declared integer.
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 приводят к возврату структуры через скрытый параметр — указатель), и можно использовать (да хоть монады на нём строить). В Паскале нет и не ожидается.
The God is real, unless declared integer.
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]?
The God is real, unless declared integer.
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>Нет. Не верю я в то, что это остановится на каких-то разумных пределах.

Оно всегда останавливается, и сильно раньше разумных пределов. Просто иначе физически не поместить в ослабленные требования к школьникам (которые возникают из-за преподавания ещё в стиле Локка, учителей "на отцепись" и жалоб типа "ой перегружены, не успеваем").
The God is real, unless declared integer.
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) или их нельзя было возвращать? вот это точно не помню.

Вроде можно. Но это тот же самый костыль.
The God is real, unless declared integer.
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<> как аргумент.
The God is real, unless declared integer.
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 и он возвращается, компилятор может сэкономить на одном копировании или даже двух, просто передав адрес целевой строки. Возврат структуры — мешает этому.
The God is real, unless declared integer.
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>Мне казалось и когда я учился, и сейчас, что сильно позже, и что сильно не хватает факультативности всякой.

Ученику всегда так кажется — "накойхер это учить?"
Только педагог с опытом знает, как именно это обучение окупается (если не идёт явным насилием).
The God is real, unless declared integer.
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> Это не слишком сложно, чтобы нужно было иметь диплом педагогического университета, чтобы понять это.


Именно, что кто не профессионал в педагогике, чаще всего не понимает принципов.
The God is real, unless declared integer.
Re[9]: Чем плох Паскаль?
От: Sinclair Россия https://github.com/evilguest/
Дата: 18.06.19 14:37
Оценка:
Здравствуйте, pagid, Вы писали:

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

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

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

Это не сломает ровным счётом ничего, кроме однопроходности компилятора.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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>И что будет, без этой строгости?

Массивы будут неидентичны, и поэтому и присвоение не пройдёт.
The God is real, unless declared integer.
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>Это и в паскале можно.

Структурой? Слишком банально.
The God is real, unless declared integer.
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>Получается, что кругом они проблемы.

По отношению к чему?
The God is real, unless declared integer.
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]: Чем плох Паскаль?
От: pagid Россия  
Дата: 19.06.19 15:49
Оценка:
Здравствуйте, Mr.Delphist, Вы писали:

MD>Арифметикой это кажется, пока знаешь только один способ организации памяти. Что делать — разбаловала нас линейная адресация.

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

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

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

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

С++ — это не современный язык.
Sapienti sat!
Re: Чем плох Паскаль?
От: LaptevVV Россия  
Дата: 20.06.19 04:15
Оценка:
C>Выскажу свое мнение:
C>Для обучения в школе как первый язык программирования с которым человек встречается Паскаль очень даже подходит.
В российских школах — как второй.
Или параллельно с русскоязычным.
Даже Константин Поляков, который преподает в родной питерской школе в профильном классе, высказался у себя на сайте, что первый язык должен быть русский.
В своем учебнике по информатике для профильных классов он так и написал — параллельно.
Слева — КуМир, справа — Паскаль.
Все основы параллельно, а потом, где указатели начались — уже только паскаль.

И еще.
Современен/несовременен — это мода.
Си, Фортран — тоже несовременны.
Если кто скажет, что они развиваются, а паскаль — нет, то это ерунда.
Смотрите Оберон и Зоннон.
Фактически — нет конторы, которая поддерживала бы паскаль на рынке.
Вот и все несовременность.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[18]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 20.06.19 04:29
Оценка:
Здравствуйте, netch80, Вы писали:

N>Тогда — несерьёзный подход. В школе ещё 99% не знают точно, кем они станут, и учить надо всему понемногу.


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

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

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

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


N>Именно, что кто не профессионал в педагогике, чаще всего не понимает принципов.


Я думаю (на основании своего опыта с профессионалами), что здравого смысла вполне достаточно.
Re[19]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.06.19 05:24
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

N>>Тогда — несерьёзный подход. В школе ещё 99% не знают точно, кем они станут, и учить надо всему понемногу.

S>Учить нужно понемногу и желательно так, чтобы это было применимо к реальной жизни, а массивы в это не влезают.

Если массивы не влезают, то только потому, что словари берут на себя их роль.
Словари — влезают сразу и серьёзно. Любая реальная задача включает в себя поиски и модификации в каком-то хранилище по ключу.

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


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

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

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

Нет. Потому что люди настолько разные, что здравый смысл, основанный только на персональном опыте, будет работать только в пределах окружения этой же персоналии.
Для результатов, которые годятся хотя бы для соседей, надо исследования, статистику, обобщение и формулировку принципов.
The God is real, unless declared integer.
Re[2]: Чем плох Паскаль?
От: pagid Россия  
Дата: 20.06.19 05:38
Оценка:
Здравствуйте, LaptevVV, Вы писали:

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

LVV>Слева — КуМир, справа — Паскаль.
LVV>Все основы параллельно, а потом, где указатели начались — уже только паскаль.
А разве не во всех учебниках так? Во всяком случае в том, который я видел точно так же. И на ЕГЭ тоже на выбор.

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

LVV>Смотрите Оберон и Зоннон.
Но они почти никого не заинтересовали. Ну и они не Паскали

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

Пока Борланд поддерживала ей пришлось настолько изменить язык, что от Паскаля там только несколько ключевых слов осталось.
Re[13]: Чем плох Паскаль?
От: pagid Россия  
Дата: 20.06.19 05:49
Оценка:
Здравствуйте, netch80, Вы писали:

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

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

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

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

Это все забавно, но что получается, что языкам, где не предусмотрено возвращение нескольких значений путь в эту новую "правильную" ОС с "правильными" системными вызовами будет закрыт? Или придется лепить страшные костыли.
Re[6]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.06.19 06:16
Оценка: +1
Здравствуйте, Mr.Delphist, Вы писали:

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

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

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

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


type real = float;

type temperature = new float;

type altitude = new float;

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

type buka = foo;

type ziuka = new foo;


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

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

type real = float
type altitude float
type temperature float

type foo struct {
  bar int
  baz float
}

type buka = foo
type ziuka foo


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

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

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


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

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

  return
    1;


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

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

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


Завезли:

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

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

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

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


И это наследование ещё и множественное. Вот виртуальных функций в нём, да, нет и не предвидится, поэтому по сравнению с традиционным наследованием типа C++/Java/etc. оно инвалидное.
The God is real, unless declared integer.
Re[7]: Чем плох Паскаль?
От: AlexRK  
Дата: 20.06.19 07:25
Оценка:
Здравствуйте, netch80, Вы писали:

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


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

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

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

А, ню-ню.

package main

import (
    "fmt"
    "net"
)

func main() {
    var foo net.IP
    var bar []byte = []byte{1, 2, 3, 4}

    foo = bar       // OH SHI~

    fmt.Println(foo)
}
Re[2]: Чем плох Паскаль?
От: elmal  
Дата: 20.06.19 08:31
Оценка: +2
Здравствуйте, LaptevVV, Вы писали:

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

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

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

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

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

ARK> А, ню-ню.

ARK> foo = bar // OH SHI~

Читайте внимательнее, вот и не будет "ню ню" или "OH SHI~":

package main

import (
    "fmt"
    "net"
)

func main() {
    type barray []byte // вот это и есть определение нового типа
    var foo net.IP
    var bar barray = []byte{1, 2, 3, 4}

    foo = bar       // ага!

    fmt.Println(foo)
}


и результат:

./prog.go:13:9: cannot use bar (type barray) as type net.IP in assignment


Не завели новый тип, воспользовались при определении переменной просто массивом — получили совместимость.
И если в первой строке main вставить '=' -скомпилируется.

ARK> Не уверен, что эти фичи являются показателем строгости типизации. ИМХО, строгая типизация — это когда нет неявных преобразований между типами разной структуры. И паскаль этому определению вполне соответствует.


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

А Паскаль — не соответствует.
Например, в нём нет запрета неявной конверсии int во float (по Borland; real — по Вирту), хотя она может дать потерю данных.
The God is real, unless declared integer.
Отредактировано 20.06.2019 14:39 netch80 . Предыдущая версия . Еще …
Отредактировано 20.06.2019 14:33 netch80 . Предыдущая версия .
Отредактировано 20.06.2019 14:30 netch80 . Предыдущая версия .
Отредактировано 20.06.2019 14:29 netch80 . Предыдущая версия .
Re[14]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.06.19 14:39
Оценка: +1
Здравствуйте, pagid, Вы писали:

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

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

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

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

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

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


Придётся лепить ровно такие же костыли, как и сейчас: заполнение нескольких раздельных значений по указателям, заполнение структуры по указателям, возврат структуры явным образом (на уровне конвенции превращающемся опять же в указатель на структуру). Ничего нового.
The God is real, unless declared integer.
Отредактировано 21.06.2019 4:42 netch80 . Предыдущая версия .
Re[9]: Чем плох Паскаль?
От: AlexRK  
Дата: 20.06.19 14:52
Оценка:
Здравствуйте, netch80, Вы писали:

N>Не завели новый тип, воспользовались при определении переменной просто массивом — получили совместимость.


Совместимость, идущую вразрез с духом golang, ибо алиаса в явном виде нет.

ARK>> Не уверен, что эти фичи являются показателем строгости типизации. ИМХО, строгая типизация — это когда нет неявных преобразований между типами разной структуры. И паскаль этому определению вполне соответствует.

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

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

N>Например, в нём нет запрета неявной конверсии int во float (по Borland; real — по Вирту), хотя она может дать потерю данных.


https://ideone.com/Vctxcc

program ideone;
var
    A: Real;
    B: Integer;
begin
    A := 33;
    B := A;
    Write(B);
end.


prog.pas: In main program:
prog.pas:7: error: incompatible types in assignment




N>А Паскаль — не соответствует.


Как видим, соответствует.
Re[10]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 20.06.19 16:57
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>
ARK>program ideone;
ARK>var
ARK>    A: Real;
ARK>    B: Integer;
ARK>begin
ARK>    A := 33;
ARK>    B := A;
ARK>    Write(B);
ARK>end.
ARK>

ARK>
Нужно наоборот — присвоить integer к float'y. При этом возможна потеря точности, если integer достаточно большой.
Sapienti sat!
Re[11]: Чем плох Паскаль?
От: AlexRK  
Дата: 20.06.19 17:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нужно наоборот — присвоить integer к float'y. При этом возможна потеря точности, если integer достаточно большой.


А! Пардон, я неправильно прочел. Да, наоборот можно. Но это почти везде можно.
Re[6]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 20.06.19 17:38
Оценка:
Здравствуйте, Mr.Delphist, Вы писали:

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

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

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

MD>Go — основан на duck-typing (ещё бы, наследования-то не завезли), и это Строгая Типизация? Лол, рофл, что там далее по списку.
Не основан. Просто использует интерфейсы вместо наследования классов, статически проверяемые, кстати.

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

Нет. Rust — это чисто практический язык, который используется (в том числе) для переписывания Firefox.

MD>E... простите, ЧТО? А, гугл подсказывает, что это препроцессор для JS, который используют все три компании, которые про него слышали. Потрясающий production!

Мы его используем.

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

MD>Похоже, насчёт строгой типизации нам говорить ещё рано
То есть?
Sapienti sat!
Re[10]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 20.06.19 17:46
Оценка:
Здравствуйте, pagid, Вы писали:

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

P>А в углубленном?
Это смотреть уже на углублённость.

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

Я бы даже проскочил мимо шестнадцатеричной системы.

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

Самое смешное, что у меня на уроках в школе как раз IEEE 754 было. Практически единственная вещь, которую я не знал сам тогда.

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

P>Как?
Вообще не преподавать информатику.

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

P>То есть на уроках информатики должны учить писать скрипты на Питоне, Matlab и наверно пользоваться Excel'ем?
Вполне возможно.

P>Ну может и так Хотя Питон в такой раскладке я бы из списка выбросил, Excel там чуток и так изучают, что там с Matlab и нужен ли он не знаю.

Всё-таки нужен какой-то язык хотя бы показать. Питон тут подойдёт как раз неплохо.
Sapienti sat!
Re[8]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 20.06.19 19:05
Оценка: +1
Здравствуйте, AlexRK, Вы писали:

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

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

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

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

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

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

N>>Не завели новый тип, воспользовались при определении переменной просто массивом — получили совместимость.

ARK>Совместимость, идущую вразрез с духом golang, ибо алиаса в явном виде нет.

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

ARK>>> Не уверен, что эти фичи являются показателем строгости типизации. ИМХО, строгая типизация — это когда нет неявных преобразований между типами разной структуры. И паскаль этому определению вполне соответствует.

N>>Непрактично.
N>>Лучше так: строгая типизация — это когда нет неявных преобразований, которые явно запрещены, могут потерять данные или принципиально изменить семантику операций со значениями.
ARK>Не вижу, чем это определение лучше. Точнее, оно гораздо хуже, потому что добавляет еще несколько связанных трудноформализуемых (если вообще формализуемых) определений.

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

N>>Например, в нём нет запрета неявной конверсии int во float (по Borland; real — по Вирту), хотя она может дать потерю данных.


ARK>https://ideone.com/Vctxcc


ARK>program ideone;

ARK>var
ARK> A: Real;
ARK> B: Integer;
ARK>begin
ARK> A := 33;
ARK> B := A;
ARK> Write(B);
ARK>end.

Вы уже второй раз в этом треде читаете полностью противоположное тому, что я писал, и приводите пример на это противоположное прочтение.
Вы уже запланировали отпуск? По-моему, пора.
The God is real, unless declared integer.
Re[12]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.06.19 19:22
Оценка:
Здравствуйте, AlexRK, Вы писали:

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


C>>Нужно наоборот — присвоить integer к float'y. При этом возможна потеря точности, если integer достаточно большой.


ARK>А! Пардон, я неправильно прочел. Да, наоборот можно. Но это почти везде можно.


Go — нельзя.

package main

func main() {
    var a int = 33
    var b float32
    b = a
}


не скомпилируется.
(Исключение — для констант.)

Там даже конверсия int32->int неявная недопустима, хотя они одного размера.

(С другой стороны, сделав этот запрет, они не озаботились качественными операторами/функциями конверсии с контролем переполнений и потерь точности, выбором режима округления и т.п.
Увы, реализация только половинная. Но направление в целом — взято правильно.)
The God is real, unless declared integer.
Re[2]: Чем плох Паскаль?
От: MamutArGud  
Дата: 20.06.19 19:26
Оценка: +1
LVV>В российских школах — как второй.
LVV>Или параллельно с русскоязычным.

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

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


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

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

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

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

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

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

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


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

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

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

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

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


«Паскаль не развивается — это ерунда», но одновременно «нет конторы, которая поддерживала бы паскаль»
Re[11]: Чем плох Паскаль?
От: AlexRK  
Дата: 20.06.19 20:09
Оценка:
Здравствуйте, netch80, Вы писали:

ARK>>>> Не уверен, что эти фичи являются показателем строгости типизации. ИМХО, строгая типизация — это когда нет неявных преобразований между типами разной структуры. И паскаль этому определению вполне соответствует.

N>>>Лучше так: строгая типизация — это когда нет неявных преобразований, которые явно запрещены, могут потерять данные или принципиально изменить семантику операций со значениями.
ARK>>Не вижу, чем это определение лучше. Точнее, оно гораздо хуже, потому что добавляет еще несколько связанных трудноформализуемых (если вообще формализуемых) определений.
N>Зато полезнее, потому что определяет важность именно сохранности данных и корректности операций с ними.

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

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

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


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

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


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

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


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


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


А то, понимаешь, "читаете полностью противоположное тому, что я писал, и приводите пример на это противоположное прочтение" (с)
Re[12]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.06.19 20:44
Оценка: +2
Здравствуйте, AlexRK, Вы писали:

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


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

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

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

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

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


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

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


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

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

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

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


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

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

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

В 7475483.

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

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

ARK>

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

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

Там было рядом с нужным, а вы полностью противоположное находите.
The God is real, unless declared integer.
Re[13]: Чем плох Паскаль?
От: AlexRK  
Дата: 20.06.19 21:44
Оценка:
Здравствуйте, netch80, Вы писали:

N>Сохранность данных: у типа A есть множество значений V(A), у B есть множество значений V(B).

N>Если ∃a: a∈V(A) ∧ a∉V(B), то конверсия A -> B может давать потерю данных, и должна быть запрещена в неявном виде.
N>Сохранение семантики: если A(), B() это конверсии к соотв. типам, и A(B(x) op B(y)) != x op y для некоторой op и некоторых a, b ∈ A, то автоконверсия A->B недопустима. (Аналогичное может быть для операций любой арности и разных типов, но облом всё расписывать.)

По-моему, это все покрывается одним моим определением — типы с разной структурой не могут быть присвоены друг другу. ИМХО, этого достаточно.

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

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



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

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

Я там просто привел пример того, что есть еще и неявные присваивания без алиасов.

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

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

Понял. Когда специально написано БОЛЬШИМИ буквами "можно ли присвоить НАПРЯМУЮ" и при этом дан ответ на какой-то совершенно иной вопрос — это "рядом с нужным". Ясно.
Re: Чем плох Паскаль?
От: __kot2  
Дата: 21.06.19 02:11
Оценка:
Паскаль устарел еще в конце 90ых, потому что оставался 16тибитным
когда его сделали 32битным, то почему-то решили, что это среда для гуя
гуй вяло поделали для десктопа некоторое время, потом забили, перешли на веб
в итоге остался паскаль ни для high performance, ни для гуя, ни для чего
ну, можно ему в универе учить. а зачем? потом все равно что-то другое учить придется
Re[14]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 21.06.19 04:35
Оценка:
Здравствуйте, AlexRK, Вы писали:

N>>Сохранность данных: у типа A есть множество значений V(A), у B есть множество значений V(B).

N>>Если ∃a: a∈V(A) ∧ a∉V(B), то конверсия A -> B может давать потерю данных, и должна быть запрещена в неявном виде.
N>>Сохранение семантики: если A(), B() это конверсии к соотв. типам, и A(B(x) op B(y)) != x op y для некоторой op и некоторых a, b ∈ A, то автоконверсия A->B недопустима. (Аналогичное может быть для операций любой арности и разных типов, но облом всё расписывать.)

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


Нет, конечно. Вот я возьму и разложу float на части:

struct float1 {
  bool sign;
  int exponent;
  uint64_t significand;
};

struct float2 {
  uint32_t mantissa_low;
  uint32_t mantissa_high;
  int ordinata;
  bool nepolozhitelno;
};


и определю конверсию между ними. Соответствие 1:1. Структура разная. Набор представимых значений один и тот же (множества значений взаимно изоморфны, при одинаковой целевой интерпретации).
Надо запрещать имплицитные преобразования? Очевидно, нет.
А если я ограничу набор значений в порядке и мантиссе, то смогу и с родным float обеспечить взаимозаменяемость (а иначе ограничу — с double). И тоже можно обеспечить это через конструкторы и операторы типа (для C++).

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

ARK>>>А где первый раз был?
N>>В 7475483.
ARK>Я там просто привел пример того, что есть еще и неявные присваивания без алиасов.

Вы там не определили новый тип, а применили существующий — вот вам и результат.
Объявление переменной не вводит новый тип, это естественно, иначе бы написав

var a int
var b int


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

ARK>Понял. Когда специально написано БОЛЬШИМИ буквами "можно ли присвоить НАПРЯМУЮ" и при этом дан ответ на какой-то совершенно иной вопрос — это "рядом с нужным". Ясно.


Нет, вы ничего не поняли. Но рекомендую на этом не циклиться, а вернуться к более актуальной части.
The God is real, unless declared integer.
Re[15]: Чем плох Паскаль?
От: AlexRK  
Дата: 21.06.19 05:17
Оценка:
Здравствуйте, netch80, Вы писали:

N>Нет, конечно. Вот я возьму и разложу float на части:

N>и определю конверсию между ними. Соответствие 1:1. Структура разная. Набор представимых значений один и тот же (множества значений взаимно изоморфны, при одинаковой целевой интерпретации).
N>Надо запрещать имплицитные преобразования? Очевидно, нет.

Надо.

N>А если я ограничу набор значений в порядке и мантиссе, то смогу и с родным float обеспечить взаимозаменяемость (а иначе ограничу — с double). И тоже можно обеспечить это через конструкторы и операторы типа (для C++).


Это уже не сильная типизация.

Кстати, а если я объявлю два типа — meter и kilometer, у обоих в базе int, «операций» в текущем модуле нет. Всё, можно присваивать друг другу?

ARK>>Понял. Когда специально написано БОЛЬШИМИ буквами "можно ли присвоить НАПРЯМУЮ" и при этом дан ответ на какой-то совершенно иной вопрос — это "рядом с нужным". Ясно.

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

Я все понял. Что кто-то виляет.
Re[2]: Чем плох Паскаль?
От: pagid Россия  
Дата: 21.06.19 06:24
Оценка:
Здравствуйте, __kot2, Вы писали:

__>ну, можно ему в универе учить. а зачем? потом все равно что-то другое учить придется

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

N>>Нет, конечно. Вот я возьму и разложу float на части:

N>>и определю конверсию между ними. Соответствие 1:1. Структура разная. Набор представимых значений один и тот же (множества значений взаимно изоморфны, при одинаковой целевой интерпретации).
N>>Надо запрещать имплицитные преобразования? Очевидно, нет.

ARK>Надо.


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

N>>А если я ограничу набор значений в порядке и мантиссе, то смогу и с родным float обеспечить взаимозаменяемость (а иначе ограничу — с double). И тоже можно обеспечить это через конструкторы и операторы типа (для C++).

ARK>Это уже не сильная типизация.

Только в ваших фантазиях.

ARK>Кстати, а если я объявлю два типа — meter и kilometer, у обоих в базе int, «операций» в текущем модуле нет. Всё, можно присваивать друг другу?


Не понимаю, что такое "<операции> в текущем модуле", но я объяснял в предыдущих примерах.

type meter = new int;
type kilometer = new int;


всё, прямая конверсия запрещена.
Если не сделали такого — сами себе буратино, контролируйте операции вручную.

OK, такого в языке нет — берём C++:

struct meter {
  int value;
  explicit meter(int nv) { value = nv; }
};

struct kilometer {
  int value;
  explicit kilometer(int nv) { value = nv; }
};


конверсии нет.

Но можно попросить:

struct kilometer {
  int value;
  explicit kilometer(int nv) { value = nv; }
  operator meter() const {
    int r;
    if (__builtin_mul_overflow(value, 1000, &r)) {
      throw overflow_exception();
    }
    return meter(r);
  }
  bool to_meter_checked(meter& target) const {
    return __builtin_mul_overflow(value, 1000, &target);
  }
};

struct meter {
  int value;
  explicit meter(int nv) { value = nv; }
  operator kilometer() const {
     div_t rd = div(value, 1000);
     if (rd.rem != 0) {
        throw inexact_exception();
     }
     return kilometer(rd.quot);
  }
  bool to_kilometer_checked(kilometer& target) const {
     // true if inexact
     div_t rd = div(value, 1000);
     target.value = rd.quot;
     return rd.rem != 0;
  }
  kilometer to_kilometer_round() const {
     return kilometer((int) round(value/1000.0));
  }
};


Всё, прямая конверсия (раз уж попросили) сделана безопасной (увы, в рантайме; но если компилятор знает, что путь исключения не выполняется, то он просто выкинет соответствующие проверки).
А кто не хочет — может добавить слово explicit к конвертерам, или пользуется другими методами классов.

ARK>>>Понял. Когда специально написано БОЛЬШИМИ буквами "можно ли присвоить НАПРЯМУЮ" и при этом дан ответ на какой-то совершенно иной вопрос — это "рядом с нужным". Ясно.

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

ARK>Я все понял. Что кто-то виляет.


Да, вы абсолютно верно посмотрели в зеркало.
The God is real, unless declared integer.
Re[17]: Чем плох Паскаль?
От: AlexRK  
Дата: 21.06.19 09:32
Оценка:
Здравствуйте, netch80, Вы писали:

N>Только в ваших фантазиях.


Что ж, разберем ваши фантазии.

Вот вторая часть вашего определения:

Сохранение семантики: если A(), B() это конверсии к соотв. типам, и A(B(x) op B(y)) != x op y для некоторой op и некоторых a, b ∈ A, то автоконверсия A->B недопустима. (Аналогичное может быть для операций любой арности и разных типов, но облом всё расписывать.)


Если автоконверсия из некоторого типа в некоторый тип _существует_ в любом виде (или встроена, или определена пользователем), то эта часть вашего определения бессмысленна, т.к. пользователь в какой-то момент и в каком-то месте определит такой "op" (а это любая функция), который приведет к инвалидации вашего правила. И мы получим, что "A(B(x) op B(y)) != x op y для некоторой op и некоторых a, b ∈ A, и автоконверсия A->B ЕСТЬ". То бишь любой язык, в котором есть неявное преобразование типов, согласно вашему определению, НЕ будет сильнотипизированным.

Таким образом, автоконверсии с "сохранением семантики" быть не может в принципе.

Если же рассмотреть варианты БЕЗ автоконверсии — ими могут быть "язык с номинативной типизацией" и "язык со структурной типизацией и два типа с разной структурой" — то эти варианты покрываются моим определением "два типа с разной структурой не могут быть присвоены друг другу".

Таким образом, та часть вашего определения, которая "про сохранение семантики", бессмысленна в любом случае — либо она входит в мое гораздо более простое определение, либо она просто не работает.
Re[17]: Чем плох Паскаль?
От: Michael7 Россия  
Дата: 21.06.19 13:15
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

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

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

А вот некоторые анестезиологи пишут. И не три строчки скриптов, а планировщики задания для ядра ОС и программы для майнинга криптовалют.
Re[3]: Чем плох Паскаль?
От: LaptevVV Россия  
Дата: 21.06.19 13:43
Оценка:
LVV>>В российских школах — как второй.
LVV>>Или параллельно с русскоязычным.
MAG>А есть хоть один нормальный русскоязычный ЯП?
И КуМир, и Рапира — нормальные языки для обучения. Рапира — ЛУЧШЕ бейсика, которому обучали студентов в Америке.
О чем высказался недвусмысленно Дейкстра.
LVV>>Даже Константин Поляков, который преподает в родной питерской школе в профильном классе, высказался у себя на сайте, что первый язык должен быть русский.
MAG>Даже! Кто такой, почему мы должны ему безоговорочно верить?
Если хотите иметь качественных программистов (о бестолковости которых вы здесь постоянно пишете) — читайте Константина Полякова.
О том, как и готовить.
Константин Поляков — лучший учитель России какого-то там года.
Он написал лучший учебник информатики для профильных классов.
И он по-любому больше вас знает, как готовить программистов.
Еще и доктор наук. Но школу родную не бросает и учит пацанов.
LVV>>В своем учебнике по информатике для профильных классов он так и написал — параллельно.
LVV>>Слева — КуМир, справа — Паскаль.
MAG>Это тот самый кумир, который алг нач цел вещ все кон? За что?
MAG>За что вы так ненавидите детей?
Ваше воиствующее невежество лезет из все щелей вашего организма...
LVV>>Если кто скажет, что они развиваются, а паскаль — нет, то это ерунда.
LVV>>Смотрите Оберон и Зоннон.
MAG>Здесь мы на них смотрели. Много раз.
Как говорится, смотрите в книгу, а видите фигу.
LVV>>Фактически — нет конторы, которая поддерживала бы паскаль на рынке.
MAG>«Паскаль не развивается — это ерунда», но одновременно «нет конторы, которая поддерживала бы паскаль»
О, Боже! Опять вы демонстрируете свое невежество.
Отсутствие прибыли — не есть отсутствие развития...
Развитием паскалевского направления занимается Вирт до сих пор и Гуткнехт, который приезжал в Россию в октябре 2018 года на День Оберона и рассказывал много интересного.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[18]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 21.06.19 17:42
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>

Сохранение семантики: если A(), B() это конверсии к соотв. типам, и A(B(x) op B(y)) != x op y для некоторой op и некоторых a, b ∈ A, то автоконверсия A->B недопустима. (Аналогичное может быть для операций любой арности и разных типов, но облом всё расписывать.)


ARK>Если автоконверсия из некоторого типа в некоторый тип _существует_ в любом виде (или встроена, или определена пользователем), то эта часть вашего определения бессмысленна, т.к. пользователь в какой-то момент и в каком-то месте определит такой "op" (а это любая функция), который приведет к инвалидации вашего правила.


Да, пользователь может что угодно определить. И тогда будет виноват, что он так определил.
Это пользовательские типы => это его забота делать так, чтобы не создавать нелепостей в определениях.
Задача языка не в том, чтобы запретить это пользователю, а в том, чтобы
1) не создавать таких проблем в своей базе;
2) предоставить пользователю средства создания нужных типов и их конверсии;
3) ещё лучше — предоставить пользователю средства контроля за проблемами типизации;
4) совсем хорошо — предупреждать о таких проблемах.

ARK>Таким образом, автоконверсии с "сохранением семантики" быть не может в принципе.


Может. Если подходить с умом, здравым смыслом и правилом "tools, not policy".
А ваш подход — лучшая в этой сфере иллюстрация к "дай дураку стеклянный фаллос, он его разобьёт и порежется".

ARK>Если же рассмотреть варианты БЕЗ автоконверсии — ими могут быть "язык с номинативной типизацией" и "язык со структурной типизацией и два типа с разной структурой" — то эти варианты покрываются моим определением "два типа с разной структурой не могут быть присвоены друг другу".


Ну вот и получаются беззубые языки, которые только для обучения подходам 50-летней давности.
Отличное доказательство $subj всей темы, спасибо.
The God is real, unless declared integer.
Re[4]: Чем плох Паскаль?
От: MamutArGud  
Дата: 21.06.19 19:28
Оценка:
LVV>И КуМир, и Рапира — нормальные языки для обучения. Рапира — ЛУЧШЕ бейсика, которому обучали студентов в Америке.

Человек, который что-то вещает про невежество, предлагает сравнивать с бейскиом, которому студентов в Америке не обучают уже лет тридцать, как. На дворе был 2019 год...

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

MAG>>За что вы так ненавидите детей?
LVV>Ваше воиствующее невежество лезет из все щелей вашего организма...

Отличная аргументация, сразил наповал, да.

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

LVV>>>Смотрите Оберон и Зоннон.
MAG>>Здесь мы на них смотрели. Много раз.
LVV>Как говорится, смотрите в книгу, а видите фигу.

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

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

MAG>>«Паскаль не развивается — это ерунда», но одновременно «нет конторы, которая поддерживала бы паскаль»
LVV>О, Боже! Опять вы демонстрируете свое невежество.
LVV>Отсутствие прибыли — не есть отсутствие развития...

В каком месте кто-то хоть что-то сказал про прибыль? Никто. Кто из нас видит в книге фигу?

LVV>Развитием паскалевского направления занимается Вирт до сих пор и Гуткнехт, который приезжал в Россию в октябре 2018 года на День Оберона и рассказывал много интересного.


Языком молоть не мешки таскать. Развития в паскалевском направлении нет. Есть унылое топтание на месте.
Re[5]: Чем плох Паскаль?
От: LaptevVV Россия  
Дата: 22.06.19 14:29
Оценка:
LVV>>И КуМир, и Рапира — нормальные языки для обучения. Рапира — ЛУЧШЕ бейсика, которому обучали студентов в Америке.
MAG>Человек, который что-то вещает про невежество, предлагает сравнивать с бейскиом, которому студентов в Америке не обучают уже лет тридцать, как. На дворе был 2019 год...
MAG>>>Это тот самый кумир, который алг нач цел вещ все кон? За что?
MAG>>>За что вы так ненавидите детей?
LVV>>Ваше воинствующее невежество лезет из все щелей вашего организма...
MAG>Отличная аргументация, сразил наповал, да.
Не менее отличная, чем предположение о ненависти к детям.
За сим откланиваюсь — вы тоже воинствующий, хотя, возможно, не такой невежественный.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[18]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 22.06.19 14:45
Оценка:
Здравствуйте, Michael7, Вы писали:

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

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

M>А вот некоторые анестезиологи пишут. И не три строчки скриптов, а планировщики задания для ядра ОС и программы для майнинга криптовалют.


Это очень хорошо. Но если мы сделаем умение писать планировщики требованием для анестезиологов, большинство хирургических операций придётся делать без анестезии. Будущие же выдающиеся анестезиологи могут в школе заниматься факультативно.
Отредактировано 22.06.2019 14:46 Sharowarsheg . Предыдущая версия .
Re[3]: Чем плох Паскаль?
От: __kot2  
Дата: 22.06.19 16:38
Оценка: -1
Здравствуйте, pagid, Вы писали:
__>>ну, можно ему в универе учить. а зачем? потом все равно что-то другое учить придется
P>Так любое другое учить будет проще, а это "другое" может оказаться очень разным.
дело во временных затратах.
нужен например тебе для работы, русский язык. а тебе говорят — ты сначала изучи болгарский, украинский и белорусский и тогда, когда будешь русский, наконец учить, будет проще и будешь глубже его понимать. так-то оно так, но все-таки это просто сильно дольше получается
Re: Чем плох Паскаль?
От: Michael7 Россия  
Дата: 22.06.19 22:09
Оценка:
Здравствуйте, Cicero, Вы писали:

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

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

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


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

Но такое ощущение, что разные люди имели ввиду разный Паскаль. Виртовский, Турбо-Паскаль, ранние версии Delphi, современные версии Delphi и FreePascal — это все очень разные языки. В Delphi в 2009 году вообще даже дженерики завезли.


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

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

C>Почему:

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

У меня такое ощущение сейчас, что программирование школьникам сейчас невозможно адекватно преподавать. Потому что все простое сейчас стало слишком оторвано от практически полезного. В эпоху турбо-паскаля на нем можно было даже коммерческие программы писать.
Re[2]: Чем плох Паскаль?
От: __kot2  
Дата: 22.06.19 22:32
Оценка: -1
Здравствуйте, Michael7, Вы писали:
M>Но такое ощущение, что разные люди имели ввиду разный Паскаль. Виртовский, Турбо-Паскаль, ранние версии Delphi, современные версии Delphi и FreePascal — это все очень разные языки. В Delphi в 2009 году вообще даже дженерики завезли.
все одинакого бесполезны. просто один чуть бесполезнее другого (сам я в школе учил и турбопаскаль и делфи)

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

ну почему — питон и жабоскрипт ва идеальных языка как раз для этого подходящих. на одном можно писать гуй и всякие примочки прикольные, на втором — даже что-то околонаучное можно сделать и без всякого знания ООП
Re[4]: Чем плох Паскаль?
От: pagid Россия  
Дата: 23.06.19 04:05
Оценка:
Здравствуйте, __kot2, Вы писали:

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


Примерно так, но с некоторыми нюансами
а) Никаких человеческих языков ты перед этим совсем не знал, инопланетянин, младенец или маугли
б) то, что нужен именно русский на этот момент неизвестно, а если известно, то какие проблемы, русский и изучай
в) не болгарский, украинский и белорусский, а некий язык имеющий общие черты со многими настоящими, но при этом весьма примитивный, и имеющий очень узкое применение, наверно эсперанто
Re[3]: Чем плох Паскаль?
От: AlexRK  
Дата: 23.06.19 07:24
Оценка: +3
Здравствуйте, __kot2, Вы писали:

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


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

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


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

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

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


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

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

P.P.S. Интересно, Валерий Викторович свою обучающую среду допилил до нормальной работы с языками?
Re[4]: Чем плох Паскаль?
От: __kot2  
Дата: 23.06.19 13:40
Оценка: +1
Здравствуйте, AlexRK, Вы писали:
ARK>"Идеальных". Жабаскрипт — это всестороннее уродство, которое для обучения просто вредно. Питон динамически типизирован и, как следствие, программы на нем подвержены ошибкам на этапе выполнения, что для обучения тоже скверно.
идеальный язык это тот, который заинтересует ученика
а не тот, который замечательный и формальный и от которого тащится только препод, но на нем ничего нельзя сделать
Re[4]: Чем плох Паскаль?
От: MamutArGud  
Дата: 28.06.19 18:15
Оценка:
P>
  qsort
MAG>>
MAG>>алг qSort(аргрез целтаб A[1:5], арг цел iStart, iEnd)
MAG>>нач
MAG>>  цел L, R, c, X
MAG>>  если iStart >= iEnd то выход все
MAG>>  L:= iStart; R:= iEnd;
MAG>>  X:= A[div(L+R,2)]
  
MAG>>  нц пока L <= R
MAG>>    нц пока A[L] < X; L:= L+1 кц
MAG>>    нц пока A[R] > X; R:= R-1 кц

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

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



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


Согласно презентации для 7 класса,

МОЖНО использовать
— латинские буквы (A-Z), русские буквы (А-Я), заглавные и строчные буквы различаются
— цифры, имя не может начинаться с цифры
— знак подчеркивания _


При этом во всех материалах используются идентификаторы на латинице.

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


Там еще много дополнительных мелочей типа:

— «Аргрез» и «арг» для аргументов функций (? или модулей?)

— «целтаб», «вещтаб», «логтаб» для массивов

— часть функций все равно на английском:
  rand/irand
.

Ну и вот, что пишет сам Поляков:

Недостатки::

— сложно мотивировать учащихся на изучение языка, который нигде не применяется;
— очень медленная работа интерпретатора (обещают существенно ускорить в версии 2.0, которая сейчас разрабатывается);
— нельзя менять значения аргументов внутри вспомогательных алгоритмов (например, в реализации алгоритма Евклида как функции приходится заводить две лишние переменные);
— нельзя вызывать функцию как процедуру, игнорируя ее результат (например, когда результат функции — код возврата и в данном случае он меня не интересует);
— неудобная и неполная справочная система;
— нет форматного вывода на консоль и в файл, как в Паскале (типа вывод x:4); это нужно, например, чтобы вывести на экран матрицу ровными столбиками.


Прям отличная система для обучения.
Re[3]: Чем плох Паскаль?
От: Лось Чтостряслось СССР  
Дата: 30.06.19 11:12
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


с Питона на С++ это ж вообще надо мозги перевернуть
социализм или варварство
Re[5]: Чем плох Паскаль?
От: Privalov  
Дата: 30.06.19 13:26
Оценка: 6 (1)
Здравствуйте, MamutArGud, Вы писали:

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


Вспомнил. Много дет назад я сталкивался с языком АП на ЭВМ Наири-3. В нем тоже все по-русски было. ИНо чтобы понять программу, нужно было знать кое-какие нюансы.
Например, оператор ВСТАВИМ — это оператор присваивания. Без него не работало а = а + 1.
Непонятно без объяснения, чем отличается КОНЧАЕМ от ОСТАНОВ.
Было еще всякое, но за давностью лет забыл все напрочь.
ЕМНИП, в АП можно было писать русские идентификаторы.
Но из-за всех этих нюансов с искажениями смысла слов на родном языке происходил взрыв мозга. И когда на горизонте появился Фортран 4, мне стало легче. Я просто запомнил английские слова, не особо вникая в исходный смысл их.
Наверное, системы программирования на русском языке нужны. Но как их правильно проектировать, я не знаю. Ясно только, что нужно привлекаьб хороших лингвистов.
P.S. Что-то я не могу найти примеров на АП. Он, видимо, давно и прочно забыт. Вот тут есть очень краткий обзор. И там же — пример программы или что-то вроде того.
Re[6]: Чем плох Паскаль?
От: pagid Россия  
Дата: 30.06.19 17:45
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Вспомнил. Много дет назад я сталкивался с языком АП на ЭВМ Наири-3. В нем тоже все по-русски было. ИНо чтобы понять программу, нужно было знать кое-какие нюансы.

А букву "Щ" на Консуле она печатала? в тех ситуациях когда винда показывает синий экран, а Линукс панику в ядре пишет
Re[7]: Чем плох Паскаль?
От: Privalov  
Дата: 30.06.19 18:14
Оценка:
Здравствуйте, pagid, Вы писали:

P>А букву "Щ" на Консуле она печатала? в тех ситуациях когда винда показывает синий экран, а Линукс панику в ядре пишет


Вот это ты спросил! Я ту Наири видел совсем недолго. На этом самом АП десяток-другой строк с Консула вбил, и на этом — всё. Как она выражала негодование по случаю сбоев, я не видел ни разу. Видимо, просто не успел.
Re[4]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 30.06.19 20:50
Оценка:
Здравствуйте, Лось Чтостряслось, Вы писали:

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

ЛЧ>с Питона на С++ это ж вообще надо мозги перевернуть
При переходе наоборот — тоже.
Sapienti sat!
Re[5]: Чем плох Паскаль?
От: Лось Чтостряслось СССР  
Дата: 30.06.19 20:59
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

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

ну в этом случае они явно есть, что уже плюс
социализм или варварство
Re: Чем плох Паскаль?
От: Lepsik Индия figvam.ca
Дата: 01.07.19 02:27
Оценка:
C>Говоря двумя словами: потому что в Паскале минимум неоднозначности синтаксиса.

Это была шутка?

напишите вложенный case на 3 уровня.
Re[2]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 01.07.19 04:26
Оценка:
Здравствуйте, Lepsik, Вы писали:

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


L>Это была шутка?


L>напишите вложенный case на 3 уровня.


Хм, а что в этом случае не так? Прошу пример кода.
The God is real, unless declared integer.
Re[8]: Чем плох Паскаль?
От: pagid Россия  
Дата: 01.07.19 07:23
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Вот это ты спросил! Я ту Наири видел совсем недолго.

А я совсем не застал. Но такая легенда передавалась студентами из поколения в поколение На самом деле за несколько лет до нас списали. Сбой получали увеличивая плавно тактовую частоту, чтоб побыстрей работала. И да, в те времена, когда легенда ходила, про синий экран винды и кернел паник, никто еще ничего не знал.
Re[9]: Чем плох Паскаль?
От: Privalov  
Дата: 01.07.19 08:50
Оценка:
Здравствуйте, pagid, Вы писали:

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


Считай, мне повезло. Я еще школьником даже что-толамповое живым видел. Глухомань, что ты хочешь. Потому, вмдимо, и "Наири" удалось попробовать немного.
Система забавная. Два оператора присваивания: ВЫЧИСЛИМ и ВСТАВИМ. Еще было ДОПУСТИМ, но это для инициализации констант или переменных. ЕМНИП, операторы пронумерованы, как в доисторическом ВАСИКе. Как сделать цикл или переход — не помню.
Немного позже мне показали распечатки на русском Коболе. Читать их было неудобно. Что-то там с падежами.
И про тактовую частоту я ничего тогда не слышал. Все мерялось в операциях в секунду.
Re[10]: Чем плох Паскаль?
От: pagid Россия  
Дата: 01.07.19 09:55
Оценка:
Здравствуйте, Privalov, Вы писали:

P>И про тактовую частоту я ничего тогда не слышал. Все мерялось в операциях в секунду.

Мы не могли не слышать, из нас не программистов делали, а проектировщиков ЭВМ. Основной учебный предмет — Теория и проектирование вычислительных то ли машин, то ли систем, не помню уже.
А программированию так, как побочному делу учили.
Re[2]: Чем плох Паскаль?
От: VladiCh  
Дата: 02.07.19 03:30
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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

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

C>Если изучать программирование, то есть две цели:

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

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


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


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


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


Вот фиг знает. Если начинать с сильно высокоуровневых концепций, то теряется целостная картина. То есть начнешь писать на Питоне с графикой, не будешь понимать как оно работает под капотом.
С другой стороны начинать с С и Ассемблера слишком хардкорно, а С++ черезчур переусложнен. Языки типа Java и С# ближе, но опять же VM не дает работать с железом напрямую, требуются пляски в бубном. Паскаль, несмотря на необычный синтаксис, довольно сбалансирован в этом смысле. По крайней мере в древней реализации от Борланда, с новыми вариантами я дела не имел да и в последний раз к нему прикасался лет 20 назад. Он был не сильно сложен, но при этом там легко можно было фигачить ассемблерные ставки и оптимизировать нужные куски. Синтаксис более читабельный, что бы ни говорили любители скобочек (или отсутствия видимых разделителей как Питоне). Более многословный синтаксис, но более читабельный (хотя это частично дело вкуса).
Вывести JPEG или звук кстати и 20 лет назад не было никаких проблем — библиотек для этого было навалом. Как первый язык для изучения он не самый лучший может быть, но и не самый плохой, даже в это древнем варианте. Для обучения вообще не очень полезно мне кажется хвататься за инструменты позволяющие давать быстрый результат в виде графики, звука и прочей чепухи. По крайней мере для детей. Потому что развлекательная часть легко перевешивает познавательную, и после получения дозы развлечения двигаться дальше будет сложнее. Это все равно что давать 6-летним детям изучать арифметику на ipad-е, а потом удивляться почему арифметика не выучена и ipad вытеснил всю учебу вообще .
Re[4]: Чем плох Паскаль?
От: VladiCh  
Дата: 02.07.19 03:38
Оценка: +1
Здравствуйте, Александр Кузнецов, Вы писали:

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


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


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


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

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

Старонорвежский был бы по логике ближе, следуя вашей логике, т.к. он гораздо ближе к староанглийскому чем латынь.
Английский если что ни разу не от латыни произошел. Заимствовал кучу слов, это да.
Ну так и Паскаль тоже многое заимствовал из более ранних языков, совершенно новых концепций в любом современном языке не сыщешь днем с огнем.
Также как и из Паскаля заимствований достаточно. Вообще практика использования учебного языка вместо промышленного имеет право на жизнь мне кажется.
Re[2]: Чем плох Паскаль?
От: Mr.Delphist  
Дата: 02.07.19 11:21
Оценка:
Здравствуйте, __kot2, Вы писали:

__>Паскаль устарел еще в конце 90ых, потому что оставался 16тибитным

Прошу прощения, но даже Borland Pascal конца 90х умел создавать 32-битные EXE, работавшие в Protected mode

__>когда его сделали 32битным, то почему-то решили, что это среда для гуя

Это про Delphi?

__>в итоге остался паскаль ни для high performance, ни для гуя, ни для чего

Это целиком "заслуга" менеджмента Borland. Сидели на попе ровно и по инерции стригли деньги за лицензии.

__>ну, можно ему в универе учить. а зачем? потом все равно что-то другое учить придется

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

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

1) Javascript вообще не требует никакой IDE, достаточно иметь: Браузер и Блокнот.
2) Легкость получения первых результатов: Создаем на диске файл hello.html, пишем в нем "<script>document.write("Hello World");</script>" и запускаем.
3) Куча примеров крутых приложений в интернете в том числе html5 игр.
4) Школьники смогут делиться результатами своих работ мгновенно со всем миром, публикуя код в интернете.
5) Язык современный и весь веб на нем держится.
Re[2]: Паскаль неплох, но Javascript лучше
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 04.07.19 11:59
Оценка: +4 :))) :))) :))
Здравствуйте, C0x, Вы писали:

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

1) Матерный вообще не требует никакой тетрадки, достаточно иметь: забор и маркер.
2) Легкость получения первых результатов: берем любую поверхность, пишем на нем "х.й" и радуемся.
3) Куча примеров крутых выражений в интернете в том числе в летсплеях игр.
4) Школьники смогут делиться результатами своих работ мгновенно со всем миром, публикуя мат в интернете.
5) Язык современный и весь веб на нем держится.
Re[9]: Чем плох Паскаль?
От: VladiCh  
Дата: 15.09.19 07:24
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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

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

Почти все это не является фичами собственно представленных языков.
Re: Чем плох Паскаль?
От: Bjorn Skalpe Земля  
Дата: 15.09.19 10:44
Оценка:
Зачем учить то, что не используется в работе? Учить нужно то, что используется...
Re[2]: Паскаль неплох, но Javascript лучше
От: AleksandrN Россия  
Дата: 15.09.19 21:25
Оценка:
Здравствуйте, C0x, Вы писали:

C0x>1) Javascript вообще не требует никакой IDE, достаточно иметь: Браузер и Блокнот.


Никакой язык не требует IDE. Среда разработки нужна разработчику для удобства работы. Но можно обойтись и без неё — достаточно текстового редактора и компилятора/интерпретатора.

C0x>2) Легкость получения первых результатов: Создаем на диске файл hello.html, пишем в нем "<script>document.write("Hello World");</script>" и запускаем.


Hello World везде легко сделать.

C0x>3) Куча примеров крутых приложений в интернете в том числе html5 игр.

C0x>4) Школьники смогут делиться результатами своих работ мгновенно со всем миром, публикуя код в интернете.

Относится к любому языку.

C0x>5) Язык современный и весь веб на нем держится.


Смотря что считать под словом "держится". Для фронтэнда — да, редко сейчас можно встретить сайт без него.
Но для бэка это не так. Node.JS популярен, но не самый популярный. PHP, Python, Java и Ruby тоже очень популярны. Самые популярные HTTP-серверы написаны на С. Браузеры — на C и C++. В процессе работы пользователя с каким-либо сайтом задействовано много софта, написанного на разных языках. И выделять какой-то один и говорить, что веб держится на нём, ИМХО неправильно.

Считаю JavaScript плохим языком для первоначального обучения именно из-за его ориентации на веб. Новичку надо будет разбираться в DOM и привязываться к браузеру. А для новичка полезнее будет узнать такие понятия, как типы данных, алгоритмы, структуры данных и как всё это использовать. Паскаль тут подходит лучше, но т.к. сейчас мало используется, сразу придётся учить ещё один язык. Поэтому начать лучше с Python.
Re[2]: Чем плох Паскаль?
От: C0x  
Дата: 16.09.19 10:21
Оценка:
Здравствуйте, Bjorn Skalpe, Вы писали:

BS>Зачем учить то, что не используется в работе? Учить нужно то, что используется...


Зачем учить таблицу умножения, я её тоже не использую в работе.
Re[2]: Чем плох Паскаль?
От: wraithik Россия  
Дата: 16.09.19 19:55
Оценка:
Здравствуйте, Bjorn Skalpe, Вы писали:

BS>Зачем учить то, что не используется в работе? Учить нужно то, что используется...


Предложи аналог?
Паскаль нужен лишь для обучения, чтобы приучить программировать.
Конечно в жизни begin-endы бесят, но мы не пишем тучу продакш-кода, а лишь учимся программировать.
И даже объявление переменных в начале функции это благо, чтобы приучить СПЕРВА ДУМАТЬ, ПОТОМ ПИСАТЬ ГОВНО КОД.

Единственная придирка к Паскалю — нет современной IDE. А Дельфи (хз че с ней щас, живет или сдохла, я после 7 как то забыл про нее) это все же не для обучения азам программирования. Хотя консольную прикладшку там вроде просто писать.

Когда я учился программировать C++ мне казался намного сложнее Паскаля. Щас — пофиг.
Re: Чем плох Паскаль?
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 16.09.19 20:27
Оценка: +1
Здравствуйте, Cicero, Вы писали:

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

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

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


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


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


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


Буханка.jpg


C>Почему:

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

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


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


Или не научит

Сишечка, а потом сипипишечка — научили меня строго контролировать то, что я пишу. А Паскаль — он не учит, он сам пытается строго контролировать. Получается весьма хреново. Угробище этот ваш Паскаль
Маньяк Робокряк колесит по городу
Re[3]: Чем плох Паскаль?
От: AleksandrN Россия  
Дата: 16.09.19 22:52
Оценка:
Здравствуйте, wraithik, Вы писали:

W>Единственная придирка к Паскалю — нет современной IDE. А Дельфи (хз че с ней щас, живет или сдохла, я после 7 как то забыл про нее) это все же не для обучения азам программирования. Хотя консольную прикладшку там вроде просто писать.


Дельфи ещё жив. Его и C++Builder купила бразильская компания Embarcadero. Есть OpenSource клон Lazarus. Судя по https://wiki.freepascal.org/IDE есть плагины для использования Паскаля в некоторых IDE, среди которых Eclipse, IDEA, MSVS.
Но я на Паскале со студенческих времён не писал, незнаю насколько современные инструменты для него сейчас есть.
Re[10]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 17.09.19 07:34
Оценка:
Здравствуйте, VladiCh, Вы писали:

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

MD>>>Имя, сестра! Имя! (ц)
C>>Go (modules), Rust (Cargo), Ruby (Gems), Python (PIP), Java (Maven).
VC>Почти все это не является фичами собственно представленных языков.
Они все являются стандартами де-факто. А то, что не в самом языке — по回。
Sapienti sat!
Re[11]: Чем плох Паскаль?
От: VladiCh  
Дата: 18.09.19 04:09
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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

MD>>>>Имя, сестра! Имя! (ц)
C>>>Go (modules), Rust (Cargo), Ruby (Gems), Python (PIP), Java (Maven).
VC>>Почти все это не является фичами собственно представленных языков.
C>Они все являются стандартами де-факто. А то, что не в самом языке — по回。

Я к тому что это не является аргументом за/против языка.
Менеджер пакетов/модулей никто не мешает для любого языка написать.
Я давно уже не в теме паскалевских дел, но вроде для Free Pascal что-то такое есть.
Re: Чем плох Паскаль?
От: Александр Кузнецов Россия  
Дата: 18.09.19 05:17
Оценка:
Дубляж.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Отредактировано 18.09.2019 8:38 Александр Кузнецов . Предыдущая версия .
Re: Чем плох Паскаль?
От: AleksandrN Россия  
Дата: 18.09.19 15:49
Оценка:
Здравствуйте, Cicero, Вы писали:

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

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

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


На Хабре проводят опрос по тому, какой язык сейчас в школе преподают. https://habr.com/ru/post/207020/
В комментариях тоже эта тема обсуждается.
Re: Чем плох Паскаль?
От: MasterZiv СССР  
Дата: 24.09.19 09:03
Оценка: +1
Здравствуйте, Cicero, Вы писали:

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


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

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

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

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

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

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


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


Это не самое большое достоинство языка программирования.

Если это единственный довод -- ну, мимо.
Re: Чем плох Паскаль?
От: MasterZiv СССР  
Дата: 24.09.19 09:07
Оценка:
Здравствуйте, Cicero, Вы писали:

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

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

Да возьми ты Python и на нём обучай.
Простой, доступный, всё можно сделать. Практичный
Re[3]: Чем плох Паскаль?
От: MasterZiv СССР  
Дата: 24.09.19 09:10
Оценка:
Здравствуйте, Слава, Вы писали:

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


С>Что там не так с указалями? Арифметика указателей есть, кастуешь указатель к integer и стреляй себе в ногу делай с ним чего хочешь, потом обратно кастуй. Linked list сделать можно, дерево — тоже.


Это должно быть встроено уже.
Re[4]: Чем плох Паскаль?
От: pagid Россия  
Дата: 24.09.19 09:12
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>Это должно быть встроено уже.

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

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


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

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


+++

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

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


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


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


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


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

Сравни с

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

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

...


А ТЕПЕРЬ НАЧНЕМ!
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
а тут мы увеличим q !
Re: Чем плох Паскаль?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.09.19 04:33
Оценка: +3
Здравствуйте, Cicero, Вы писали:

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

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

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


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

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

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

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

C>Почему:

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

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

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

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

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

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

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

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

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

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

А не так, что вот вам сложение, вот умножение, вот деление с остатком, всё, теперь вы знаете всю математику — А ТЕПЕРЬ РЕАЛИЗУЙТЕ-КА МНЕ ШИФРОВАНИЕ НА ЭЛЛИПТИЧЕСКИХ КРИВЫХ!
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Чем плох Паскаль?
От: Vlad_SP  
Дата: 26.09.19 07:15
Оценка:
Здравствуйте, Sinclair,

S>Раз мы учим программированию, то, наверное, должна получаться программа. [........]

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

Я полностью поддерживаю и твои аргументы, и аргументы коллеги Александра Кузнецова, но хотелось бы обратить внимание еще на один аспект (о чем я уже писал много-много лет назад).

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

Ведь из "среднего" такого школьного класса профессиональными программистами станут дай то Б.Г. 1-2% учеников. Остальные станут — доярками, писателями, водителями, поварами, врачами... ну и так далее, список профессий можно расширять до бесконечности. Зачем им "реальное промышленное программирование"??? Кой черт водителю сдался этот самый Паскаль или там не дай Б.Г. JavaScript ?
Вот возьмем к примеру девочку, мечтающую стать балериной. На уроках алгебры условная Марь Ванна талдычит что-то про свои синусы и катеты. Да девочка забудет все эти катеты как страшный сон, на следующее же утро после сдачи ЕГЭ! И ровно то же самое произойдет, когда на уроках "программирования" условный Сан Сеич будет ей талдычить о каких-то переменных, циклах и не дай Б.Г. каких-то "замыканиях".

Факультативно (факультативы там в школе, кружки программирования и т.д.) или "с углубленным изучением" — эт да. А в обычной-то средней школе тот же Паскаль — зачем??
Re[3]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 26.09.19 09:06
Оценка:
Здравствуйте, Vlad_SP, Вы писали:

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


Конкретные Pascal или JS — вряд ли. А вот общее понимание, как запрограммировать даже какое-то относительно тупое устройство сделать то, что им нужно — это важно каждому.
Например, может быть регулирование обогрева квартиры в зависимости от времени суток, дня недели, количества людей в квартире и т.п.
Сейчас для такого обходятся табличными методами, списками и тому подобным, но это недостаточно гибко. А чем дальше, тем больше потребуется такой гибкости и умения её применить.
Это в быту. И по профессии:
— доярка? может, у каждой коровы своя специфика, сколько пытаться выдаивать.
— писатель? даже задача переименовать персонажа во всех падежах может требовать работы
— повар? интеллектуальный контроль готовности блюда, зависимость рецепта от концентрации ключевых веществ в образце сырья...
да если подумать, будут тысячи примеров, как умения программировать можно применить, если не лениться.

V_S>Вот возьмем к примеру девочку, мечтающую стать балериной. На уроках алгебры условная Марь Ванна талдычит что-то про свои синусы и катеты. Да девочка забудет все эти катеты как страшный сон, на следующее же утро после сдачи ЕГЭ! И ровно то же самое произойдет, когда на уроках "программирования" условный Сан Сеич будет ей талдычить о каких-то переменных, циклах и не дай Б.Г. каких-то "замыканиях".


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

И, кстати, в рамках anecdotal evidence: долгие годы майнтейнером groff был дирижёр симфонического оркестра. Уж на что гуманитарная профессия

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


Ну с заменой языка на что-то более универсально-скриптовое вроде Питона — таки полезно всем.
The God is real, unless declared integer.
Re[3]: Чем плох Паскаль?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.09.19 10:55
Оценка: 3 (1)
Здравствуйте, Vlad_SP, Вы писали:

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


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

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

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


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

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

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


НЕТ.
Ребёнок должен иметь возможность стать кем угодно.
Начальная школа даёт ему возможность в обществе существовать — потому что без базовых навыков чтения, письма, и счёта он тупо не сможет квартплату оплатить и в магазине консервы отличить друг от друга.
Средняя школа даёт возможность выбрать, кем становиться.
Высшая — стать этим кем-то.
Исходя из этого, программирование должно помочь детям понять, что такое программирование вообще, и как оно устроено. Даже чтобы руководить программистами, начислять им зарплату, или заказывать у них работу, желательно представлять себе, как всё это работает.
Вот примерно как я себе всё это вижу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Чем плох Паскаль?
От: AlexRK  
Дата: 26.09.19 11:08
Оценка: +2
Здравствуйте, MasterZiv, Вы писали:

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


Это мнение либо круглого дурака, либо тролля. А Вирт за паскаль получил премию Тьюринга.
Re[4]: Чем плох Паскаль?
От: Vlad_SP  
Дата: 26.09.19 11:41
Оценка:
Здравствуйте, Sinclair,

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


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

S>.... потому что в наше время совсем-совсем не умеющий программировать человек не выдерживает требований времени.


Ой! Вот это уже натягивание совы на глобус. Умеет программировать Тимченко? Ротенберг? Алекперов? Потанин?
Ну ланна, не будем брать миллионеров. Вот был такой Жорес Алферов — академик, нобелевский лауреат и все такое. Умел программировать? А скажем известный писатель Даниил Гранин?

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

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

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

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

Вот! Это правильная точка зрения. Только я бы немного иначе сформулировал: "Исходя из этого, школьный курс информатики должен помочь детям понять, что такое..." и далее по тексту. Нет?
Причем именно "курс информатики", а не конкретно "программирование" (ну или там "шахматы", как сейчас модно) или конкретно Паскаль. В рамках этого курса можно и нужно дать школьникам понятие об алгоритме, пару-тройку простейших программ и т.п., и как это можно использовать (а можно и не использовать) в жизни. Тут уж хоть Паскаль, хоть Бейсик, хоть черт в ступе, — все хорошо. А уж всякие там "кортежи", "функторы" и иже с ними — для 99% школьников останутся пустым звуком на уроке. Кому интересно — добро пожаловать на факультатив.
Re[5]: Чем плох Паскаль?
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.09.19 15:30
Оценка: +1
Здравствуйте, Vlad_SP, Вы писали:

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


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


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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

Ок, отлично. Что за "простейшие программы" вы им собираетесь давать? Пока что я не вижу ничего такого, что вышло бы за уровень языка Лого.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.