Только хотел вам о том же написать. А точнее о части про:
различные образовательные траектории
В школах таки всё ещё учат процедурному программированию. И я ни в 1 момент не говорил про то, что типы вроде Text языку не нужны.
А вот химику из текущего контекста, который не школьник и поэтому не имеет причин быть привязанным к устаревшему процедурному стилю - он таки не нужен.
Учиться - лучше сразу современному.
А вот это никто и не опровергает)) Кроме школьных программ.
Но речь-то шла не о том, чтобы мы за пресловутого “химика” тут решали, что ему нужно, а что нет - он и сам не мальчик, разберется. Речь о том, нужны ли процедуры в языке. По крайней мере, в Вашем изначальном посте не было сказано, что речь идет о Ваших рекомендациях конкретному человеку.
Если брать именно оригинальный пост - это явно был ответ конкретному человеку.
В смысле? Конечно нужны. Я сразу сказал
То есть, другими словами - нужны но редко.
Ага. Т.е. я “наивно купился”. И @Admin повелся тоже. Может быть, все же не так явно следовало из поста, что это Ваше личное мнение о конкретном случае? )))
В фильме “Apocalypse Now” есть момент, когда полковник Курц гладит свою лысину и приговаривает: -Ужас…ужас…ужас…
Примерно так я делаю, когда читаю пояснения о функциях и процедурах 
Метаксихлордиэтиламинометилбутиламиноакридин" - это проще, конечно…
Тут всё логично
Хотя там тоже в зависимости от используемой системы формирования названия - название может быть совершенно не узнаваемое.
Допустим, если я указываю форматированный вывод Writeln - могу я называть это процедурой?
Writeln само по себе процедура.
А форматный вывод :7:3 внутри вызова Writeln - это просто часть выражения.
Ага… Прямо как у Марка Твена (полностью, например, здесь):
— Ах ты, несчастье какое! — возмутился негр и, набрав в грудь воздуха, выпалил:
— Я поймал шраттертроттэльхоттентоттэнмуттэраттэнтэтэрлаттентиттэрветтэркоттэрбойтельраттэ!
Вот кого!
Тут начальник подскочил, точно подброшенный пружиной:
— Так что же то же ты мне сразу не сказал этого так коротко и ясно, как сейчас?
Можете. Это называлось раньше в Паскале “оператором”, но по факту, поскольку в записи нет ключевых слов, это типичная процедура. В реализации PascalАВС.NЕТ это будет, скорее всего, методом.
А вот это и я не понял. Как по этому принципу от функции можно отличить?
Это один из признаков того, что конструкция не является оператором языка. А далее, поскольку она не возвращает значения, то она - процедура.
Если Вы кипятите воду в чайнике и Вам нужна именно эта вода - то это аналог процедуры. Была вода в чайнике - и осталась вода, только с измененными свойствами. Если же Вы кипятите воду с целью получить пар - это уже функция: вода, как таковая, Вас не интересует, интересует то, что вышло из носика чайника.
пример про воду - отличный. Тут всё ясно, спасибо. Программирование так далеко ушло в область чистой абстракции, что знакомые слова теряют связь с реальностью. Это создаёт необходимость овладеть специальным языком, для овладения самим процессом. Так оно везде, конечно, но программирование ещё и многопланово.
Забыл сказать, что функции еще бывают с побочным эффектом. Это как было с химиком Кадэ, который, если помню верно, нагрел в колбе уксуснокислую калийную соль в смеси с окисью мышьяка. Функцией было получение первого в мире синтезированного элементоорганического соединения. Побочным эффектом - то, что Кадэ этого узнать не успел…
Если серьезно, у функций побочный эффект - это изменение переданных ей параметров. Ведь кипяченая вода, оставшаяся в чайнике при получении пара - уже не та вода, что была до этого. Побочный эффект может быть преднамеренным (когда Вы о нем знаете и учитываете) и непреднамеренным - из-за ляпа программиста (и это кошмар пользователя).
К счастью, Паскаль предохраняет от побочных эффектов и если Вы хотите изменить параметр, перед ним надо указать var.
Уважаемые коллеги, у меня возник вопрос по мере чтения ваших ответов. Вот, например, Sun_Serega уже много раз писал о том, что учиться кодить надо сразу в современном стиле. Я полагаю, что это нужно для работы в команде. Когда над одним проектом работают много людей (индусы, китайцы и т.д) - единый стиль изложения в таких условиях, конечно, важен. В противном случае так ли важен этот современный стиль написания программ? Кому нужна эта “чистота крови”, если код никому после не виден?
Я никогда не работал в команде, не знаю что для этого нужно.
А стили программирования придуманы чтоб код который писал месяц назад - было не так сложно читать. Да и в принципе чтоб минимум багов допускать.
Каждый раз когда я писал что плохо - я старался говорить на каких багах это обычно отражается. К примеру тут:
// отражение вокруг главной диагонали
function Transpose<T>(self: array[,] of T): array[,] of T; extensionmethod;
begin
if self.GetLength(0) <> self.GetLength(1) then
raise new System.InvalidOperationException('Матрица должна быть квадратная');
Result := Copy(self);
for var x := 1 to self.GetLength(0)-1 do
for var y := 0 to x-1 do
Swap(Result[x,y], Result[y,x]);
end;
begin
var m := Matr(2,2,
1,2,
3,4
);
m.Println;
Println;
m.Transpose.Println;
Println;
m.Println;
end.
Тут Transpose возвращает изменённую копию матрицы, поэтому старая матрица не изменяется.
В процедуре если и сделать var-параметр и копировать массив - в итоге вы всё равно меняете старую переменную.
А в функциональном стиле если вы получили матрицу после .Transpose - можно не боятся за переменную m, она к этой новой матрице - вообще никак не относится.
“Современный стиль” в программировании - это не дань некоей моде. Это использование технологий уровня, соответствующего нынешнему развитию компьютерной техники, это более совершенные инструменты в руках программиста, это стиль мышления отличный от того, который складывался десятки лет назад. Программирование выросло из прежних коротких штанишек и должно отвечать нынешним требованиям. Таким, как надежность созданного кода, легкость его написания и понимания, простота модификации, удобство в отладке и сопровождении, приемлемые сроки разработки. И так далее, и так далее.
Можно ли писать код без всего этого? Можно, конечно же. Для себя и под себя. Но тогда оставить надежду, что Вам будут помогать искать ошибки, потому что любителей копаться в древнем мусорном коде не так уж и много. Не “пищать”, если Ваши программы будут давать не то, что Вы ожидаете. Не иметь возможности поделиться своими программами с коллегами. Получить большую головную боль, если через год-другой Вы захотите вернуться к использованию фрагментов своих программ. В общем, быть сектантом никто не запрещал.
А существует ли какой-нибудь методический материал, где описан современный код в понятном формате? Ну, например, как формальные требования к статьям в журналах. В ваших книгах есть, конечно, пример, но этого мало для понимания - что такое новый стиль? Можно ли рассматривать как описание такого стиля книгу Валерия Рубанцева. " Функциональное программирование на Паскале"?
Это как делать спецификацию по трендам. Пока напишете книгу - всё перевернуться успеет. Да и в целом стиль программирования - это и есть тренд.
Хотя есть вещи которые долго не меняются. Но, по моему, проще узнавать походу дела, когда кто то окликает вас и говорит что плохо и почему, и как можно лучше.
Материала много, но он непрограммисту малодоступен. Вот, к примеру, есть достаточно популярная книга Стива МакКоннела, которая называется: “Совершенный код”. Но если рекомендовать ее Вам - у нас на форуме скоро будет “тихо съехавший химик”. Валерий Рубанцев пишет прекрасно и его книги рассчитаны, в первую очередь, на аудиторию школьного возраста. Но современный код - это вовсе не обязательно код в функциональном стиле (автор, кстати, и не претендует на учебник по современному коду). Более того, написать всё в функциональном стиле на PascalАВС.NЕТ - это не для слабонервных. Оптимум обычно дает смесь функционального программирования и объектно-ориентированного. Вот так, с разгона, я даже и не могу порекомендовать Вам что-то, как “Библию современного кода”. Тут подумать надо. И крепко.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021