Программируете ли вы на Паскале?

Нет, такого в современном С++ нельзя увидеть, такое можно увидеть только у душевнобольных.

Дельфи просто с неимоверной скоростью компилирует, по сравнению даже с Qt

С каких это пор Qt стал компилятором?

А если ты имеешь в виду кресты, которые под капотом у Qt, то тут как раз всё понятно. У паскаля есть нормальная модульность в отличие от, а на скорости сборки это сказывается очень существенно.

«Какой-то паскалист» - это случайно не Брайан Керниган или Роб Пайк? :)

Robert Griesemer studied at the ETH Zurich, where he did his doctorate under the supervision of Niklaus Wirth

vM, sabacs

Если посмотреть на топ TIOBE, то на первом месте мы увидим Python, в котором используются тайп хинты в стиле Паскаля

Я объяснил почему так, реализовать типы в стиле С сложнее, во вторых такое проще впихнуть в уже готовый язык.

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

Zig, Swift, Rust - ну прям мейнистрим, мейнстрим. Вот в языке на котором работают интернеты, PHP, типы пишутся как в С.

Противоестественный сишный синтаксис объявления переменных например приводит к хорошо известным неоднозначностям в крестах:

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

Говорить что в Rust, Typescript и прочих используется синтаксис паскаля, это вообще странно, там используется синтаксис из какой то функциональщины, там нельзя сделать var a, b: type;

зачем вообще при вычислении значения простыми действиями увеличивать переменную на 1

Затем что на ряде платформ были специальные инкрементные регистры и такой синтаксис мог там давать более оптимальный код без оптимизатора.

Как собрать программу - нужна отдельная схема

Это было актуально для всех языков. Турбо-среды и IDE появились сильно позднее.

Вариант 1. Ты выберешь с++ потому что для числодробилок (а мы про них) это (увы) наилучшее решение сейчас.

нет времени ждать полдня завершения компиляции

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

Божественный язык это математика а не паскаль.

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

Попробуйте собрать qtwebengine )

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

Ну, справедливости ради, для числодробилок действительно скорость компиляции менее важна. Но это лишь одна из областей применения, в других местах цены могут быть другие. И другой вопрос - каким компилятором компилируете? В llvm есть баги (много), про gcc не в курсе. Где гарантия, что компилятор мимо не наоптимизирует? Как этот вопрос решается на практике?

Ну за удобство приходится платить.

А в чём удобство? Я уже один раз спросил, ты не ответил. Ответишь? Конкретно, чем порядок слов тип - модификаторы - имяПеременной - параметрыТипа лучше чем порядок слов имя - тип - параметрыТипа - модификаторы? Ну не совсем так даже в Паскале, но в первом приближении. Я могу сказать, чем паскалевский вариант лучше: если тип составной, то всё равно всё выражение читается слева направо. В случае Си выражение нужно читать как-то из середины, притом лексически эта середина непонятна, её нужно подбирать методом проб и ошибок. Либо иметь в голове парсер с большим lookahead-ом, а это, естественно, дорого и сложно.

Вот в языке на котором работают интернеты, PHP, типы пишутся как в С.

Я на это уже отвечал. Есть прогресс. Вариант как в Си был моден и был вариантом по умолчанию некоторое время. Потом до всех дошло, что это ошибка, и стали делать по-другому. В Scala, кстати, тоже как в Паскале, хотя этот язык простым никак уж не назвать.

Я давно уже не студент, но наши кода тоже быстро компилируются.

den73 отладчик ушиб, а Вас видимо компилятор?

Компилятор обычно gcc, реже интел.

Ошибки ловятся функциональными тестами, как обычно.

чем порядок слов тип - модификаторы - имяПеременной - параметрыТипа лучше чем порядок слов имя - тип - параметрыТипа - модификаторы?

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

такого в современном С++ нельзя увидеть, такое можно увидеть только у душевнобольных.

У душевнобольных из корпораций, которые наживаются на бедных любителях интернета?

template <typename Functor, typename Tuple>
auto apply(Functor&& functor, Tuple&& t)
    -> decltype(utility_internal::apply_helper(
        absl::forward<Functor>(functor), absl::forward<Tuple>(t),
        absl::make_index_sequence<std::tuple_size<
            typename std::remove_reference<Tuple>::type>::value>{})) {
  return utility_internal::apply_helper(
      absl::forward<Functor>(functor), absl::forward<Tuple>(t),
      absl::make_index_sequence<std::tuple_size<
          typename std::remove_reference<Tuple>::type>::value>{});
}

https://raw.githubusercontent.com/abseil/abseil-cpp/master/absl/utility/utility.h

library code is collected from Google’s own C++ code base,

https://raw.githubusercontent.com/abseil/abseil-cpp/master/AUTHORS

а Вас видимо компилятор?

И не один. Собирать мир, например, в gentoo, - так себе занятие было.

Мне тоже не нравится когда какой то сторонний пакет из сырцов собирается 10 минут. Но это плата за оптимизацию кода, это не проблема с/с++

N: Word;

Это что ещё за расизм?

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

Так уже выбрали и делают, и выбрали почему-то не как в Си. Я привёл примеры порядка 10 новых языков, в том числе самых топовых из новых. Ты же уже согласился, что C++ - паршивый язык, зачем теперь его защищать? Опять же, единообразие - это не про истину и научных работников, это армейское словечко.

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

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

Чтобы написать эти тесты, нужно представлять себе устройство компилятора. У вас принято представлять, или считается, что компиляторы достаточно надёжны? Это на самом деле вопрос не в рамках полемики, а просто интересно. С учётом того, что баг с делением залез даже в Pentium, по идее в компиляторах должны быть баги, ведущие к неверным вычислениям с плавающей точкой. Но я не в курсе, насколько это проблема на практике. Из общих соображений понятно, что чем больше оптимизаций - тем сложнее тестирование и больше вероятность не найти ошибку. Просто, если в компиляторе N флагов даже вида вкл/выкл, то нужно 2^N наборов тестов, т.к. флаги взаимодействуют между собой. Глядя на gcc, я пребываю в сомнениях на тему того, насколько он хорошо протестирован. Методически можно объявить некое сочетание флагов священным и всегда работать только с ним. Что же касается Intel, то это закрытый компилятор и вообще неясно, что он делает. Но не знаю, как это решают. Всё же вам, наверное, в первую очередь важно, чтобы результат был правильный, а если он получается в 10 раз быстрее, но неправильный, то такой результат не нужен.

А время ничего не стоит, да. )

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

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

В идеале то что считает код сравнивается в каких то частных случаях с аналитическим решением (если оно известно).

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

Я это утверждаю на основе своего опыта и опыта коллег. Простейшая везь - замена -O3 на -O0 радикально ускоряет компиляцию.

А вообще это отдельная сложная тема о которой я с Вами говорить не хочу - Вы вон с куда более простыми вещами разобраться не можете…

Ты же уже согласился, что C++ - паршивый язык, зачем теперь его защищать?

Нехорошо выдергивать слова из контекста. С++ ужасный ЯП, но для НАШИХ задач он в настоящий момент ЛУЧШИЙ.

единообразие - это не про истину и научных работников, это армейское словечко.

Опять Вы со своими бурными фантазиями… скажем математические обозначения единообразны. Лично Вы конечно можете поменять обозначения + и - местами (любовь к свободе и тд и тп), но остальное сообщество Вас не поймёт.

Код это всего лишь запись некоторого алгоритма. Хорошо бы что бы обозначения в этой записи были общепринятыми.

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

С интеловским Фортраном на рубеже 2010 с каждым обновлением что-то, да не так. Не ломается только то, что не меняется. Чаще, конечно, в стандартных библиотеках, которые приходится время от времени оптимизировать под очередное поколение.

А в чём удобство?

Удобнее читать, заводить, и записывать типы. В С не нужен TPointerToPointerImageBuffer.

У душевнобольных из корпораций, которые наживаются на бедных любителях интернета?

Тут decltype(), этот пример записан в C/C++ стиле, его нельзя записать убрав auto.

«в C/C++ стиле» это как?

Нехорошо выдергивать слова из контекста. С++ ужасный ЯП, но для НАШИХ задач он в настоящий момент ЛУЧШИЙ.

И где я выдергивал слова из контекста? Что Вы признали, то я и сказал. Ваших задач мало. Я не выдернул слова из контекста, о отбросил Ваш контекст как частность. Вернёмся к вопросу, насколько обосновано, что студентам нужно учить плюсы, а не Паскаль. Вы не отреагировали никак на мои пассажи про истину и уклонение от неё. Отреагируете или не ждать?

Хотя бы уж сузьте тогда Ваше утверждение: студенты, которые заведомо знают, что будут заниматься вашими числодробилками, должны учить C++. Должны ли даже они при этом не учить Паскаль? Паскаль настолько проще плюсов, что дополнительные трудозатраты ничтожны, а последствия для кругозора при этом значительны.

скажем математические обозначения единообразны

Ну и что дальше, к чему Вы начали про единообразие? Предлагаете утвердить C++ как стандарт задания числодробилок на веки вечные, поскольку на сегодня лучше его для вашей предметки ничего нет? Или что? Не совсем до конца выражена мысль.

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

Тут тип записан не после имени функции, а до и после одновременно. В примере

auto i() -> int { return 0; }

int i() { return 0; }

а последствия для кругозора при этом значительны

Как ты это измеряешь?

По себе. Хотя Паскаль от Си мало отличается. Реально расширение кругозора в студенческие мне дал Форт, хоть я на нём ни строчки не написал, а только прочитал книжку. Но уж учить языку с неудобным и устаревшим порядком слов в определениях и не учить другим - это выглядит как целенаправленное нанесение студентам вреда. Для меня эта разница с порядком слов большую часть времени была неочевидна, я её понял только тогда, когда сам начал разрабатывать ЯП. И лишь задним числом понял, что каждый раз, работая с Си, я зря жрал кактус. Основной причиной отторжения Си, имея опыт работы с Дельфи и Лиспом, были тормоза против Дельфи и убожество выразительных и инструментальных средств + низкая надёжность против Лиспа. Тут просто Сям вместе с плюсами совсем нечего делать, при сравнении они выглядят ну просто совсем безнадёжно. А то, что там ещё и плохо с порядком слов, на этом фоне - мелочь. Однако эта мелочь означает совершенно конкретные в цифрах убытки для той организации, которая возьмёт этот язык при прочих равных, я не говорю про особые случаи, когда альтернатив нет, как у числодробильщиков (если это правда, конечно).

С чего Вы взяли?! На матлабе и R работают некоторые экспериментаторы и всякие социологи.

А также финансисты, банкиры, страховщики, биологи, фармакологи, психологи, маркетологи, экономисты, политологи и все остальные, чья работа непосредственно связана со статистическим анализом данных (разумеется, R и Matlab - тут лишь пример сред, отличных от «голого» C++, на практике это может быть и SPSS, SAS, Minitab, и куча всего другого).

Тотально доминируют расчеты в КБ/НИИ, и считают там на специализированных мультифмзичных программных комплексах которые сделаны именно на плюсах. Интерфейс пиотновский или свои гуй/DSL.

В отдельной области - охотно верю. Но мир не сводится к решению одного типа уравнений на вычислительных кластерах.

Т.е. нельзя вместо

template <typename Functor, typename Arg>
auto apply(Functor&& functor, Arg&& t)->decltype(functor(t))
{
  return  functor(t);
}

написать что-нибудь вроде такого?

template <typename Functor, typename Arg>
decltype(Functor{}(Arg{})) apply(Functor&& functor, Arg&& t)
{
  return  functor(t);
}

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

template <typename Functor, typename Arg>
decltype(auto) apply(Functor&& functor, Arg&& t)
{
  return  functor(t);
}

Мне понравилось. как парой страниц ранее кто-то жаловался на то, что в Си препроцессор «может изменить язык до неузнаваемости».

Да. Может.

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

Тем не менее, во всём, что не касается препроцессора, язык Си стабильно соответствует принципу:

Код компилируется дословно ровно в то, что в нём написано.

Отсутствие скрытой логики.

Это в ряде случаев — важная черта.

А теперь возвращаемся в Паскаль.

Вот так в Паскале выглядит обращение к переменной a:

x := a;

А вот так в Паскале выглядит вызов функции a:

x := a;

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

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

Без препроцессора на Си вообще невозможно программировать. :)

Вот так в Паскале выглядит обращение к переменной a:

И в чем проблема?

Без препроцессора на Си вообще невозможно программировать

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

И в чем проблема?

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

В том, что ЛЮБОЕ обращение к имени объекта на самом деле может оказаться вызовом функции.

ЛЮБОЕ.

А это означает, что для понимания скрытой логики ЛЮБОГО фрагмента кода, нужно помнить определения ВСЕХ упомянутых там имён.

Это вот «отличная» читаемость кода, за которую хвалят Паскаль. Хвалят люди, которые застряли на уровне студентов первого курса. Которые дальше чтения ключевых слов не смогли продвинуться.

Которые не понимают, что в работе с кодом читать и понимать приходится не begin и end а СЕМАНТИКУ написанного.

Где тут не однозначность? Не могут одновременно существовать переменная и функция с одним идентификатором.

// собирается
template <typename T1, typename T2> 
auto apply_good(T1 t1, T2 t2) -> decltype(t1+t2)
{
  return t1+t1;
}

// не собирается
template <typename T1, typename T2>
decltype(t1+t2) apply_bad(T1 t1, T2 t2)
{
  return t1+t1;
}

Это будет прекрасно работать:

template <typename Functor, typename Arg>
decltype(auto) apply(Functor&& functor, Arg&& t)
{
  return  functor(t);
}

Вы слышали про такую вещь как абстракция? И не любое, кстати.

А это означает, что для понимания скрытой логики ЛЮБОГО фрагмента кода, нужно помнить определения ВСЕХ упомянутых там имён.

Для понимания того что вычисляется в выражении нужно понимать что находится в переменных.

Тотально доминируют расчеты в КБ/НИИ, и считают там на специализированных мультифмзичных программных комплексах которые сделаны именно на плюсах.

Это и внушает опасения за судьбу страны. В российских (военных) КБ /НИИ доверяют закрытому компилятору Intel или бесплатному сыру из мышеловки gcc, а также бесплатному сыру в виде OSS библиотек и пользуются мерзопакостным ЯП. А потом всё это летит бомбить врагов, ну или в ближайшее болото. Налицо факт недостатка кругозора у тех, кто в своё время пришёл в эти НИИ/КБ и сформировал де-факто стандарт. А почему так случилось? По двум причинам:

• выученная беспомощность. Вместо написания своего ЯП и компилятора для этого, который бы заслуживал доверия, взяли бесплатный сыр. Потому что считается, что создать компилятор - слишком сложно. Конечно, создать компилятор C++ сложно, но для числодробилок он и не нужен. Нужен простой надёжный ЯП и надёжные библиотеки. В СССР считать умели хорошо, может быть нужно просто поскрести по сусекам. А может быть, отказаться от выученной беспомощности. Если этому ЯП нужны встроенные примитивы для работы с матрицами или перегрузка операций - это не рокет сайенс, для этого вовсе не нужно городить тот кошмар, каковым является C++
• кто-то кому-то в своё время посоветовал учить С++ вместо Паскаля или иных адекватных ЯП.

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

Код компилируется дословно ровно в то, что в нём написано.

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

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

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

Но Паскаль - очень годный язык. Если кто на него ругается, то буду с ним драться.

Для понимания того что вычисляется в выражении нужно понимать что находится в переменных.

Особенно если переменные являются функциями. Бгг. Пример из куска кода, что был парой страниц ранее:

while not(Eof(Fil)) do
	if (FuncRead > 0) and {Проверка первого числа}
	   (FuncRead > 0) then {Проверка второго числа}
			Inc(N); {Увеличение счётчика пар}

При чтении этого кода… Оказывается! необходимо знать, что FuncRead — это не переменная, а функция, которая имеет сайд эффекты и возвращает разные результаты!

И эти люди еще жалуются на макросы.

Очевидно что в любом случае нужно знать что такое FuncRead. Тем более что их названия это вполне очевидно.

Да, это плохо Вирт сделал. Значимость этого не очень велика, поскольку не так много функций без параметров. Иногда, да, можно наступить на грабли. Не сказал бы, что это драматично.

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

А бывает и по-другому. Кто-то другой взялся за препроцессор, а ты потом скачиваешь программку из сети и ни сном ни духом не подозреваешь, что printf подменён на burn_this_computer. И нет, это не форма хирургического вмешательства. #include есть в любой программе и на Си, и на плюсах. Так что это необходимый элемент инфраструктуры.

Затем что на ряде платформ были специальные инкрементные регистры и такой синтаксис мог там давать более оптимальный код без оптимизатора.

Может быть, особенно во время цикла, но это уж очень «низкоуровнево». Инкремент - нужен. Читать счётчик - нужно. Одновременно делать и то, и другое - сомнительно. По крайней мере, встроенными командами языка. Когда же это действительно надо - несложно сделать специальную функцию, или же довериться оптимизатору, который эти действия объединит.

Вообще, проблема С-подобных языков - объединять необъединяемое. Действие не должно возвращать результата, или же возвращать булевый результат - получилось или нет. Если же оно возвращает результатом то, что само и сделало - теоретически, можно сэкономить строчку кода (a=b=c), но практически в большинстве случаев это источник потенциальных проблем. В Паскале никто и не подумает, что возможен аналог С-шного if (a=0), даже если записать его как if a:=0 then… - мухи (присваивание) отдельно, котлеты (результат сравнения) отдельно.

Это было актуально для всех языков. Турбо-среды и IDE появились сильно позднее.

Понятно, что древние компиляторы Паскаля (которые не знали модулей) работали так же, но что поновее - уже компилятор сам подтягивает нужное. Возьмите fpc безо всякой IDE. И, главное (пусть и не все это любят), прямо в .pas-файл можно прописать, где что искать (uses Unit1 in «units/unit1.pas»;) Да, это не 80-е, но для того язык и развивается, чтобы решать требуемые задачи. В том числе и задачу отбрасывания ненужных сущностей.