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

Какие в жопу итераторы

В этом он прав - в plain-C всё слишком примитивно чтобы это стало проблемой. По крайней мере контр-пример я сходу не придумал. Но фундаментальный посыл оно не отменяет.

Погодь, если мы про сложные итераторы - то там что ++, что next, что ещё какая фигня - разницы с т.з. производительности никакой.

Если мы про простые итераторы - то ты скорее прав чем неправ (и они в pure C точно есть:-)).

Погодь, если мы про сложные итераторы - то там что ++, что next, что ещё какая фигня - разницы с т.з. производительности никакой.

А она есть (между ++ and advance()). Разница в implicit «likely», если ты сейчас понимаешь о чём я…

Уже всё обосоали в треде по 3 раза, нет, ска, давай 4 круг нарезать.

обосоали

Как мило. Мне нравится.

Опечатка по Фрейду, ага.

Опечатка по Фрейду, ага.

Мне гораздо более интересно: unC0Rr - это ваш виртуал, или нет? Так ловко поддакивает…

зачем тогда господин Вирт вводил в Паскаль Inc() и Dec()?

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

Потому что эти студенты будут работать на плюсах а не на расте/обероне.

освоение ЯП это самый простой этап.ю профессии числодробильщика.

Взаимоисключающих параграфов не замечаешь? Со вторым пунктом я в целом согласен. И в частности, поэтому вопрос «на каком ЯП будут работать студенты» не является определяющим. Скорее всего, в профессиональной деятельности ЯПов им придётся поменять сильно больше одного. И более того, полезно, чтобы они этому научились ещё в учёбе, чтобы не фетишизировать никакой ЯП.

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

А попытки сразу обучить людей «универсальному языку для всего» уже приводят к тому, что этим языком оказался питон, который для сложных программ, мягко говоря, неоптимален. Честное слово, авторы классического бейсика из 70-х (современной альтернативой которого питон и является) были честнее: они позиционировали его как язык программирования для непрограммистов и не пытались пихать в каждую дырку.

О, вот этот комментарий (он в ту же тему) почему-то не заметил вовремя:

Приходят потом в тред юные анонимусы с неокрепшими умами, читают это все - и давай фортраны с паскалями учить!:-(

Знание фортранов с паскалями НИКАК не помешает юным анонимусам при необходимости выучить хоть плюсы, хоть жабу, хоть раст. Главное, чтобы говнокод не писали.

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

Знание фортранов с паскалями НИКАК не помешает юным анонимусам при необходимости выучить хоть плюсы, хоть жабу, хоть раст

Помешает ли знание фортрана? Думаю нет.

https://github.com/Reference-LAPACK/lapack/blob/master/SRC/cgeev.f#L291

Но может тогда лучше изучить код лунного модуля на ассемблере? Тоже интересно же, и в примерно таком же стиле:

https://github.com/chrislgarry/Apollo-11/blob/master/Luminary099/GIMBAL_LOCK_...

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

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

Нужность такого перехода, немного сомнительна.

Я вот вовремя не освоил, и теперь уже поздно, видимо, мозги не те…

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

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

Сомнительная аналогия. Брейнфак он именно про намеренное повышение сложности. Если человек осилил брейнфак, для него даже ассемблер легкотнёй будет.

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

Но поскольку я тут не Копенгаген и даже не Осло — призову в тему max_lapshin, он про это (в частности, про Erlang) знает намного больше меня. :)

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

На С++ можно писать в функциональном стиле, возможно все же снижают сложность не языки, а определенный стиль написания?

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

На Си без плюсов можно писать в ОО-стиле, и даже пишут (GTK, некоторые места из Linux Kernel), но выглядит это куда вырвиглазнее, чем в плюсах, и менее безопасно.

Я так же думал в 16 лет, мысль была такая, вот я начинал с си

Как мило.

а теперь мышление в стиле фп мне недоступно, закостенел мозг.

Аж подпрыгнул. И что же такого случилось? И откуда ножки «закостенения» растут? Очередная «Джава головного мозга»?

А это разве уже не после него Борланд придумал?

То как я это вижу - люди хотя бы понимали что они делают.

Аж подпрыгнул. И что же такого случилось?

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

Очередная «Джава головного мозга»?

Виноват С, ну а что поделать, если структуры, юнионы, енумы и процедуры это очень удобно.

Когда я учился у нас один поток учили плюсами, второй паскалю. Паскалистам, я считаю, не повезло.

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

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

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

просто языки плохо пригодны для обычных задач

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

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

Да ладно

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

набирается в техе

набирается в техе но совсем другое

Если не секрет — какие это годы и в каком вузе?

Физфак МГУ, 1990е. Но диплом я писал в одном из НИИ РАН (где до сих пор и работаю).

Поправь меня, но

iterator::next()
iterator::operator ++ ()

стоят совершенно одинаково, компилятору оно что в лоб что полбу. Никаких циклов там и в помине нет?

стоят совершенно одинаково, компилятору оно что в лоб что полбу. Никаких циклов там и в помине нет?

Всё правильно. Речь исключительно об ++ vs += const в контексте итераторов.

В контексте базовых типов как я понимаю, т.е. для интов. Для сложного типа, когда операция перегружена, уже пофиг?

В контексте базовых типов как я понимаю, т.е. для интов. Для сложного типа, когда операция перегружена, уже пофиг?

Как раз для интов - всё монопинесуально (там всё ровно). Делай что хочешь. Посыл был исключительно в контексте наличия inc / next (называй как хочешь) в случае user-defined-types и перегруженных операций.

Тогда яннп:-(

По моим представлениям, перегруженный оператор от обычного метода класса отличается только синтаксисом?

По моим представлениям, перегруженный оператор от обычного метода класса отличается только синтаксисом?

Всё правильно. Вопрос исключительно во что это разворачивается.

И то и то разворачивается в вызов функции или инлайнится?:-)

И то и то разворачивается в вызов функции или инлайнится?:-)

Вопроса не понял…

void iterator::next(){...}

I.next()

или

void iterator::operator ++ (){...}

I++;

В чем будет разница после компиляции? Все остальное совпадает.

Мне кажется - ты не до конца понимаешь за что я здесь борюсь. Я утверждаю что операция «next()» (в противовес next(N)) - имеет право на жизнь сама по себе. Вот и всё :)

А шо, кто то против?!:-)

А шо, кто то против?!:-)

Не поверишь… Их даже больше одного… тынц раз, тынц два, тынц три. Спешу заметить - это все разные люди. Я в шоке.

Зачем тогда господин Вирт вводил в Паскаль Inc() и Dec()? Задумайтесь.

Задумайтесь, почему господин Вирт ввёл в свой Паскаль функции succ() и pred(), но не стал вводить псеводофункции Inc() и Dec() с побочными эффектами?

Эге ты как лихо обобщаешь. Я сказал, что пишу += для интов, даже если речь об обычном for(int i = 0; i < 100; i += 1), нигде не писал, что операция next() не нужна, тем более для полноценных итераторов.

зачем тогда господин Вирт вводил в Паскаль Inc() и Dec()? Задумайтесь.

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

Задумайтесь, почему господин Вирт ввёл в свой Паскаль функции succ() и pred(), но не стал вводить псеводофункции Inc() и Dec() с побочными эффектами?

на всякий случай советую ознакомиться: https://ctp.mkprog.com/en/pascal/increment_statement/

Я сказал, что пишу += для интов, даже если речь об обычном for(int i = 0; i < 100; i += 1),

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

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

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

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

сторона важна только в составе выражения.

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

Я уже больше десяти лет назад на хаскеле написал транслятор с паскаля в си

и что? если вы до сих пор задумываетесь с какой стороны ставить крестики в операторе инкремента - значит вам это не помогло. не ну знаю… попробуйте написать компилятор из си в паскаль что-ли.

https://ctp.mkprog.com/en/pascal/increment_statement/

Указанный Вами текст господин Вирт писал?

В конце п.14 The Programming Language Pascal (Revised Report), 1973 Niklaus Wirth привёл список стандартных процедур, функций и других стандартных идентификаторов Pascal.

https://standardpascal.org/The_Programming_Language_Pascal_1973.pdf#page=49

Functions:
abs,  sqr, odd, succ, pred, ord, chr, trunc, eof, sin, cos, exp, ln, sqrt, arctan, round
Procedures:
get, put, reset, rewrite, new, read, write, pack, unpack

Аналогичный список есть в Приложении C к Стандарту MЭК/ИСО 7185 Pascal 1990 года

Required identifiers

abs           6.6.6.2
arctan        6.6.6.2
Boolean       6.4.2.2
char          6.4.2.2
chr           6.6.6.4
cos           6.6.6.2
dispose       6.6.5.3
eof           6.6.6.5
eoln          6.6.6.5
exp           6.6.6.2
false         6.4.2.2
get           6.6.5.2
input         6.10
integer       6.4.2.2
ln            6.6.6.2
maxint        6.7.2.2
new           6.6.5.3
odd           6.6.6.5
ord           6.6.6.4
output        6.10
pack          6.6.5.4
page          6.9.5
pred          6.6.6.4
put           6.6.5.2
read          6.6.5.2, 6.9.1
readln        6.9.2
real          6.4.2.2
reset         6.6.5.2
rewrite       6.6.5.2
round         6.6.6.3
sin           6.6.6.2
sqr           6.6.6.2
sqrt          6.6.6.2
succ          6.6.6.4
text          6.4.3.5
true          6.4.2.2
trunc         6.6.6.3
unpack        6.6.5.4
write         6.6.5.2, 6.9.3
writeln       6.9.4

В Extended Pascal ( ИСО/MЭЛ 10206:1990)

http://pascal.hansotten.com/uploads/standardpascal/iso10206_a4.pdf#page=174

список обязательных идентификаторов шире, но в нём тоже нет ни Inc(), ни Dec()

если вы до сих пор задумываетесь

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

откройте стандарт модулы-2 и там есть INC/DEC.

Несколько иной язык по области применения:

PROCEDURE INC(VAR v : type; amount : CARDINAL);

amount неотрицательный ?

CARDINAL - неотрицательные числа. аналог - insigned int в сиподобных

Этим, а также отсутствием возвращаемого значения INC(v, amount) в Модула-2 отличается от v+=amount в Си.