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

S>>>Хештаблицы и прочие структуры данных сложнее, чем переменная в смысле integer или double.
N>>Зато это принципиальная возможность, которая всегда будет использована на практике и полезна для задач.
S>Теми, кто пойдет в хирурги, эта возможность не будет использована никогда.

Именно эта возможность будет постоянно использоваться, если он вообще будет что-то автоматизировать.
DB-like операции "посмотреть/уточнить параметры пациента".
Управление операциями типа "если появится кровь вот в этом сегменте изображения, подать тревогу" — и таких сегментов обычно несколько, и их желательно называть.
Ну и так далее.

S>>>>> Сумму чётных элементов последователности, или предел последовательности, или что-то такое.
N>>>>Ну если в языке будет абстрактная последовательность, то он станет чем-то вроде Хаскеля.
S>>>Никаких абстрактных последовательностей, а просто циклом вычислить сумму элементов ряда, типа a(n)=1/n
N>>Вы намеренно дали пример на расходящийся ряд?
S>Да. Не будем же мы выбрасывать из школьной программы арифметическое переполнение? Или выбросить?

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

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

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

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

N>>Не так. В исходном Pascal у функции, кроме возвращаемого значения, ещё одно свойство: отсутствие побочных эффектов — нельзя присваивать ничего за пределами, нет var-параметров. Сейчас это принято называть, что функция чистая (pure).
P>Что-то сомневаюсь, паскалевские и функции и процедуры могли быть вложенными, а им доступны все переменные описанные "выше" и если мне не изменяет мой склероз никаких ограничений на из изменение в Паскале нет.

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

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

Вроде можно. Но это тот же самый костыль.

Здравствуйте, 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<> как аргумент.

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

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

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

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

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

S>>>>Хештаблицы и прочие структуры данных сложнее, чем переменная в смысле integer или double.
N>>>Зато это принципиальная возможность, которая всегда будет использована на практике и полезна для задач.
S>>Теми, кто пойдет в хирурги, эта возможность не будет использована никогда.

N>Именно эта возможность будет постоянно использоваться, если он вообще будет что-то автоматизировать.

Я про хирургов говорю. Это такие дядьки (и тетки), которые стоят у операционного стола с ножом и режут людей, а потом обратно зашивают иголками и нитками. Не тех, которые автоматизируют, как у Брукса в книжке.

N>DB-like операции "посмотреть/уточнить параметры пациента".
N>Управление операциями типа "если появится кровь вот в этом сегменте изображения, подать тревогу" — и таких сегментов обычно несколько, и их желательно называть.

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

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

N>Оно всегда останавливается, и сильно раньше разумных пределов.

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

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

N>Я ж говорил — у Borland многие ограничения уже ослаблены.
Вложенные процедуры/функции были в языке изначально.

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

Здравствуйте, 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 и он возвращается, компилятор может сэкономить на одном копировании или даже двух, просто передав адрес целевой строки. Возврат структуры — мешает этому.

Здравствуйте, 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<> как аргумент.

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

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

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

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

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

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

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

Ученику всегда так кажется — "накойхер это учить?"
Только педагог с опытом знает, как именно это обучение окупается (если не идёт явным насилием).

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

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

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

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

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

C>>А зачем?
P>А зачем в школе предмет — информатика? Может и не нужен

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

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

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

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

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


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

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


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

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

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

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

N>Ученику всегда так кажется — "накойхер это учить?"
N>Только педагог с опытом знает, как именно это обучение окупается (если не идёт явным насилием).

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

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

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

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

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

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

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

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

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

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

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

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

a:int := 0;

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

Это не сломает ровным счётом ничего, кроме однопроходности компилятора.

Здравствуйте, 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 и того больше, можно чётко указать, где два типа — синонимы, а где — действительно неприсваиваемые друг другу, несмотря на побитовую идентичность в бинарном представлении.

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

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

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

С чего это вдруг?

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

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

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

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

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

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

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

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

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

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

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

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

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

Total Commander!

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

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