Re[13]: Чем плох Паскаль?
От: AlexRK  
Дата: 15.06.19 08:07
Оценка:
Здравствуйте, netch80, Вы писали:

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


x = a + (b * c);

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

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

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


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


Да

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

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

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

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


Да. Не упираться в суммы чётных элементов, потому что это массивы, а массивы — тоже лишнее. Сумму чётных элементов последователности, или предел последовательности, или что-то такое. Поиск корня уравнения делением пополам, или ещё что-то типа такого (после того, как это в математике изучили). Я помню у нас была задача "нарисуйте движение планет солнечной системы, без масштаба". Ну то есть нужно нарисовать несколько кружочков (или точек), движущихся по окружностям вокруг центра. Отдельные бонусы за Луну и кольца Сатурна. Этого достаточно. Все желающие узнать, что такое хештаблица, и чем отличается криптографический хеш от используемого в хештаблице, приглашаются на факультативные занятия информатикой.
Re[5]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 15.06.19 13:44
Оценка: +6
Здравствуйте, netch80, Вы писали:


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


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


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



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


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

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




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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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


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

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


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

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


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

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

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

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

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

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

Я бы не сказал, что это шум.
А в начале появляется шум. Даже не шум, а куча г.
Кстати, про RAII слышал?


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


И зачем это нужно?


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

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

А, про RAII таки слышал, уже лучше?
И зачем добавлять это слово?
Придумал какие-то сложности на ровном месте, решая какую-то непонятную проблему.

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



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

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

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


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


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

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

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

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

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

Если это нарушается, то компилятор об этом скажет. Но зато Си позволяет вообще не привязываться к переменной цикла, а проверять условие выхода другими способами, которые лишь косвенно связаны с переменной цикла.
Я отвечаю за свои слова, а не за то как вы их интерпретируете!
Re[8]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 16.06.19 06:36
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

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

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

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


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

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

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


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

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

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

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

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

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

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

  // Tie together all our conditions.
  Result = Builder.CreateBinOp(Or, EqZero, AdjEq);
  Result = Builder.CreateBinOp(And, PtrEq, Result,
                               Inequality ? "memptr.ne" : "memptr.eq");
  return Result;
}
Re[6]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 16.06.19 07:03
Оценка:
Здравствуйте, Marty, Вы писали:

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

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

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

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

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

M>И зачем это нужно?
Незнаю но многие упорно хотят видеть где переменная впервые использеутся. С этим спокойно спраиться IDE просто подсвечивая имя под курсором по всему тексту.
  Скрытый текст
https://i.imgur.com/glCtE2Y.png

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

...
M>Какой замечательный код, который позволяет легко нарваться на неинициализированную переменную
Как раз нет. Посмотрите язык zig если ваша переменная должна быть не инициализированны то это надо объявить явно иначе вообще не компилируется.
Re[5]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 16.06.19 12:58
Оценка:
Здравствуйте, qwertyuiop, Вы писали:

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

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

Q>Если это нарушается, то компилятор об этом скажет.


Не на каждый случай. Только если такой переменной нет или ещё в паре аналогичных банальных случаев.

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


Так они все позволяют. if (условие) break; внутри цикла.
Re[3]: Чем плох Паскаль?
От: MamutArGud  
Дата: 16.06.19 12:58
Оценка:
C>>В современном варианте было бы лучше что-то типа Питона с графической средой. Или как вариант: https://www.apple.com/swift/playgrounds/ — лучшее, что я вообще видел для детей.

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


В каком месте Swift динамически типизиурем?
Re[8]: Чем плох Паскаль?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.06.19 13:48
Оценка: -1
Здравствуйте, Sharowarsheg, Вы писали:


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


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

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


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


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


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

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

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

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


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

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

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

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

И о минусах:

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

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

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

Если эти стандартные обрамления поставляются готовыми, они ученикам не мешают.
Но если есть смысл в их изменении (а он есть, где можно менять), то надо иметь возможность их менять и надо, чтобы была возможность у учеников заинтересоваться ими.
Жёсткое begin и поехали, как в случае Паскаля, тут не помогает.

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


Видимо, вы рассуждаете про досовский Turbo Pascal. Это уже никуда не годится.

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


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

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


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

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


scf>И о минусах:


scf>25х80, текстовый интерфейс и запуск через dosbox — некруто.


Ну так есть много новых средств типа FreePascal, Pascal.ABC...
Но они страдают теми же системными проблемами языка.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.