Андрей Викторович Столяров: сайт автора

Ну поехали по порядку.

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

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

Что касается трудоустройства, программистом на чистом Си можно устроиться разве что во всякий embedded, и этот рынок довольно компактный. Кроме того, пожалуй, человек без опыта работы и с дипломом философа может у потенциальных работодателей вызвать достаточно предвзятое отношение.

Вообще если уж хотите моего совета, то рискну вам таковой выдать. Коль скоро вы освоили первые два тома моего учебника (речь ведь идёт об освоении, а не о "прочтении"?), то уж с чем у вас категорически не может быть проблем — это с командной строкой Юникса (включая Linux). Попробуйте для начала куда-нибудь устроиться сисадмином, только ни в коем случае не виндовозным, а именно на всякие юниксы; на такие места работодателю с удовольствием людей берут и без дипломов (это вообще работа, не требующая в/о, если уж честно), и без опыта, в ряде случаев вполне достаточно продемонстрировать, что вы командной строки не боитесь и обращаться с ней умеете; лучше, конечно, уметь ещё и простейшие сетки настраивать, но это вроде не так трудно. За время работы сисадмином можно попробовать что-нибудь сваять opensource'ное на том же Си, и опыт наберёте, и портфолио (в резюме ссылка на опубликованную оpensource'ную программу весьма способствует). Если даже и нет, всё равно полтора-два года опыта работы сисадмином поднимет вашу привлекательность в качестве кандидата в программисты. Да и третий том за это время осилите :-)

Думаю, что нет. На одном императивно-процедурном программировании далеко не уедешь.

Вы бы ещё за операционную систему сразу схватились.

В принципе оконник — не так чтобы совсем суперсложная программа, но уж точно это не для того периода, когда человек ещё сам для себя не понял, может ли он быть программистом (кстати, в вашем случае скорее всего всё в порядке, вы просто слишком спешите).

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

Ну а рекомендация тут будет очень простая: вернитесь к первому тому, к части про Паскаль, и для начала на Паскале (!) напишите что-то такое, чем станет пользоваться (причём добровольно) кто-то кроме вас. В процессе как раз наберёте опыт простейшего кодинга.

Что до оконника — первое, что приходит в голову, это сделать какой-нибудь бесполезный, но работающий оконник, например, чтобы он вообще вокруг окошек ничего не рисовал, любое окошко появлялось изначально в середине экрана (полностью игнорируя другие окна), и чтобы это появившееся окошко можно было двигать, например, клавишами F9--F12. Потом постепенно обращивать полученный скелет новым мясом, несколько раз наверняка придётся переписать с нуля (когда код начнёт от рук отбиваться), но это нормально. Только не делайте этого прямо сейчас!. Что делать сейчас — см. выше.

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

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

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

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

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

В данном случае скорее я что-то упускаю, точнее, упустил столько лет назад, сколько прошло с публикации версии 0.3.10. scrtest — это файл с юнит-тестами, то есть на функционирование библиотеки он никак не влияет, но, конечно, в архиве он вроде бы должен быть.

Прошу прощения, но прямо сейчас это исправлять не буду, постараюсь в ближайшее время выложить версию посвежее (только сам себя убедю, что она более-менее рабочая, и тут же выложу)

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

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

Сто раз уже сказано -- никак, ибо это не баг, а фича. Текстовый слой в этих PDFах сломан намеренно. Я уже даже в FAQ это вынес, сколько можно одно и то же спрашивать?!

Это очень сильно зависит от того, какие требования вы сами предъявляете к своей реализации. Если вас устраивает рассмотрение этого автомата на каком-то поле фиксированного размера, то вам хватит материала первого тома до главы про полноэкранные программы включительно. А вот если фиксированное поле не устраивает, то потребуются динамические массивы, Free Pascal их поддерживает, но я их намеренно не рассматриваю в книге, чтобы не лишать читателя стимула осваивать указатели и списки; да и вообще, чтобы понять, почему они такие "странные", нужно знать Си :-) (они оттуда импортированы, причём довольно кривенько). Ну и вообще, как, например, задавать исходную колонию? Будет ли ваша реализация позволять сохранять конфигурацию в файле и считывать из файла? Будет ли предусмотрен какой-то интерактивный редактор или пользователю придётся, скажем, самому в текстовои файле рисовать эту колонию звёздочками или ещё чем? Будет ли размер поля совпадать с размером экрана или вы позволите колонии разрастаться на большем поле, а для просмотра прикрутите всякий скроллинг? Всё это влияет на сложность реализации.

Но простейший вариант можно сделать сразу после изучения модуля crt :-)

Видимо имеются проблемы с поиском информации :-)

Я за минуту нашёл вот-такую pdf'ку. Осталось только попробовать.

Вообще не обязательно даже читать эту pdf'ку. Достаточно оставить свободное место на диске при установке первого дистрибутива, и второй (сколько угодно) ставить на это свободное место, к тому же можно на разных OS использовать один swap раздел, "даже" один /home и "даже" настроить общие разделы (у меня это /public). И одной update-grub точно хватить.

Я у cебя второй системой держу FreeBSD, загружаю её с GRUB. Там плясок побольше, но всё возможно.

Бггг. А что, по-вашему, может этому помешать?

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

Вот тут есть неплохой обзор на тему "что можно сделать" (рекомендую выключить js, текст на странице доступен без него) https://security.stackexchange.com/questions/142947/what-can-i-do-about-...
Самый простой из советов — не пользоваться набортным эзером. Там, правда, советуют usb ether, а это не очень хорошая идея, поскольку в линуксе с драйверами для usb ether'ов полная задница. Можно ли использовать просто сетевую карту, вставленную в PCI-слот, и умеет ли ME ими пользоваться — я не понял.

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

В книжке всё написано — все мои рекомендации и прочие соображения по поводу этих двух задач. А решать в любом случае вам.

>НГТУ
Это Нижегородский или Новосибирский? В Нижегородском моя информатичка училась :)

Гм, "секта свидетелей Столярова" — ну а что, звучит :-)

Вообще это ожидаемо, и не только это, смею вас заверить. Своими книжками, особенно текстом предисловий, я совершенно откровенно заявил, что примерно 97% преподавателей программирования, если не больше — халтурщики. Я вполне отдаю себе отчёт, какое количество врагов я себе при этом нажил, и их число будет только увеличиваться по мере роста популярности моих книг. Понимаете, в этой игре такие правила. "Они" вам будут доказывать что угодно и сколько угодно времени — просто потому, что признать себя халтурщиком никто никогда не захочет и не согласится.

Ну а ценность аргумента, что, мол, людям придётся с линуксом "мучиться", можете оценить вполне объективно: вот лично я что, так похож на мазохиста? Совершенно очевидно, что, когда припрёт, с мелкомягким дерьмищем я справляюсь (что после этого руки трясутся и хочется кого-нибудь убить — это второй вопрос). Ну то есть вот лично я могу работать и с Windows, и с Linux. Могу, разумеется, под Linux'ом работать и с Desktop Environments, и с командной строкой. Умею, не поверите! Точнее, вы-то поверите, да и любой другой человек, если подумает, вряд ли поверит, что я не умею тыкать мышкой в иконки. Не люблю — это факт, но понятно, что умею. И из всего этого сборища альтернатив, разумеется, выбираю именно что командную строку для всего, кроме разве что сортировки фоток (там предметная область такая — превьюшки удобны).

А вот виндузятники работать к командной строкой не умеют. И с этим тоже обычно никто не спорит, потому что просто никто в обратное не поверит. И если я, умея и то и другое, выбираю командную строку, и не просто выбираю, а только с ней фактически и работаю вот уже больше четверти века — значит, (surprize!) она просто удобна. А мучаются не те, кто с работают с линуксом, а те, кто до полной ус$$чки, пардон, боятся сделать шаг в сторону от мейнстрима, и продолжают гонять отвратительные в своей контр-эргономичности GUI. Вот они — да, мучаются. Большинство соверменных людей проводят за компьютером много часов в день, можно было бы и потратить чуть-чуть времени, чтобы научиться с компьютерами работать нормально, т.е. грамотно и эффективно, а не так, как тридцать с лишним лет назад приучили весь мир поганцы-маркетоиды.

Сайт же не такой большой на самом деле.

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

А дальше grep в руки и вперед)

Вот это не получится, извиняйте. Движок сайта в состоянии EOL уже лет десять по меньшей мере.

Извините, а как туда присоединится? Я пока зелёный, прошу не бить :)

Вот вы смеетесь над убогими, а они вон целый установщик системы на джавапитон переписали!
https://www.opennet.ru/opennews/art.shtml?num=56494

Странная какая-то новость.

Зависимости - это, безусловно, зло, но тут получается какое-то зло во плоти, дышащее адским жаром. Разработчик изменил коды какой-то библиотеки, выложил их в репозиторий, и куча систем в мире, зависящих от данной библиотеки, сразу сломалась? Значит, разработчики этих систем те еще молодцы: получается, у них была зависимость не от конкретной версии библиотеки, а от последней актуальной.

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

Такими темпами серверные js-макаки самоликвидируются собственными силами. А там, глядишь, и браузерные последуют примеру.

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

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

Можете писать мне :). У меня есть сайт http://bimzhanovt.net/ , а там мой email, пишите я только рад. Правда сайт пока сырой, но, что точно, что через некоторое время там появится контент.

Вот даже змейку можно забрать для изучения git clone git://git.bimzhanovt.net/quetzalcoatl.git :D, на паскале CRT, но она не коммитилась уже как месяц и явно годится для переделки (не судите строго).

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

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

===

Кстати, Андрей Викторович работает ли у обычных юзеров форма контакта? По крайней мере я открыл O_o

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

А что, когда Вам кто-то начнет обьяснять термин "в живую", Вы его лучше поймете, чем тогда, если найдете на другом ресурсе в Интернете ответ? По-мне, так проще перелопатить Интернет, чтоб понять что-то, что не понятно. Лично я не вижу проблем с этим вообще.

> Часто возникают затруднения, связанные с освоением материала, задачей или нужен совет.

Интернет - полон советов! Серьезно!

> Качество ответов посредственное, на той стороне не всегда внимательно читают вопрос, но это не страшно.

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

> Я хочу спросить мнения здесь, одному мне интересно платить за возможность получать оперативно ответы или вы тоже считаете организацию такой схемы хорошей идеей?

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

Для этого вообще тут давным-давно предлагали xmpp-чатик сделать, но не срослось. А имхо, но он вот прям нужен.

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

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

Правильнее -- если программа не интерактивная, то не говорить ничего, пока об этом не попросили (или пока не "вынудили", сделав ошибку -- об ошибке нужно сообщать).

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

А почему вот такой код не компилируется?

Потому что язык Си так устроен

Получается, что фигурные скобки вокруг тела функции — это не то же самое, что в других местах?

Как ни странно — ни фига. Есть в Си такое понятие — составной оператор, он же блок. Так вот телом сложного оператора (цикла или ветвления) может быть любой оператор, в том числе блок, ведь это тоже оператор; а телом функции можно быть только блок.

может ли что-то быть между закрывающей круглой скобкой и открывающей фигурной в декларации функции

Рекомендую погуглить, какой синтаксис всего этого безобразия был предложен изначально (так называемый K&R C). Между прочим, прекрасно поддерживается компиляторами до сих пор.

Если синтаксис K&R проигнорировать как артефакт доисторической эпохи, то в чистом Си вроде бы между заголовком и блоком ничего быть не должно. А вот в Си++ — сколько угодно.

Но омонимия с этими злосчастными скобками вообще-то присутствует, только не там, где вы её ожидаете. В операторе switch фигурные скобки обязательны и при этом они не являются блоком — там нельзя описывать локальные переменные. UPD: тут я оказался неправ, память иногда выделывает странные штуки.

На самом деле 8 MB хватит с головой, вон в MacOS X размер стека 512 KB. Судите сами, даже в большой программе будет не больше 10ти стековых фреймов, если пустить рекурсию на дерево высотой 20 (что уже дофига, 2^20-1~1'000'000) будет ну 30 максимум. Если не хватает, вы явно что-то неправильно делаете, всё.

UPD: как у вас malloc в системный вызов превратился :-) ?

Господи, ну malloc-то зачем? Вы же не собираетесь потом этот кусок памяти возвращать в кучу? Тот самый случай, когда правильнее вызвать напрямую mmap, если уж совсем припёрло. А ещё нужно будет озаботиться, чтобы та функция, в которой вы всё это непотребство провернули, никогда не пошла дальше и никогда не вернула управление.

Хотя правильнее тут скорее провести с самим собой сеанс психотерапии. Ну, например, ответить самому себе на вопросы, а почему не хватает стека? а почему 8MB не хватает, а 1GB точно хватит? а не жирно ли 1GB? а по каким таким причинам тянет на всё большое, может причина не в программах? и, может быть, компенсировать собственные комплексы как-то по-другому, ну там купить себе джип побольше и пострашнее?

Если серьёзно, то не должно такого быть, чтобы стека не хватило. Если его не хватает — вы просто делаете что-то не то.

Документация — это текст на естественном языке. Не вижу проблем, документация вообще не обязана быть просто текстом, она может быть в другом формате. Хотя, конечно, те же RFC обходятся чистым текстом и алфавитом ASCII, и это правильно.

Думая и т.д. можно закончить на изучении Си и устройства ОС. Получается не очень-то и долго: 1-1.5 года плотного изучения при наличии желания.

А "непрограммисту" Си++ с лиспами и не нужен. На выходе он/она сможет SQL и Python за 2 вечера с документацией и узучить.

SQL — это не язык программирования, это язык запросов.
Изначально он предназначался не для программистов, а для пользователей базы данных. Если требуется прямо отличное его знание с пониманием нюансов разных СУБД — это странно.

А Python — ну если его требуют, значит им требуется программист всё-таки, верно? А тогда и образование должно быть соответствующее.

И ещё вопрос какой уровень знания Python вообще требуется. Если просто прочитать готовые скрипты и изредка что-то поправить — это одно, а если прямо писать новый код на этом языке — другое.

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

Конечно, есть: немедленно сменить работу. И свой мозг целее будет, и окружающему миру вреда не нанесёте.

А вы хранение ЭТОГО готовы доверить файлу .bash_history? А не стрёмно? А ну как потеряется, не задолбаетесь воспроизводить?

Если же хранить, как положено, в файле, то получается

a=1
b=1000000
while ((c=(a+b)/2,b-a>1)); do
    seq $c | ./foo &>/dev/null && a=$c || b=$c
done
echo $a $b

И это я ещё не начал ваши нагромождения выражений расписывать по-человечески.

Файл даже скриптом объявлять не обязательно и бит x навешивать, достаточно его "втянуть" через точку:

  . mycmd.sh

А теперь как это должно выглядеть на самом деле:

a=1
b=1000000
while true; do
  c=$(( (a+b)/2 ))
  [ $b -le $a ] && break
  if seq $c | ./foo &>/dev/null ; then
      a=$c
  else
      b=$c
  fi
done
echo $a $b

NB: пока я вашу гениальную команду не превратил мысленно вот в это, до меня не доходило, как она вообще должна работать. Так что не обольщайтесь, такие заклинания нечитаемы. Вообще, совсем нечитаемы. И отнюдь не только из-за выхода за 80-ю колонку, хотя это тоже свою лепту вносит.

Слушайте, как это вообще можно сравнивать? В Паскале write забит ржавыми гвоздями в ядро языка (это там даже вообще не процедура, оно компилируется в последовательность вызовов процедур для печати конкретных типов), тогда как в Си в самом языке вообще нет ввода-вывода, так что printf не знает (ну не может знать, это же не джава какая-нибудь с рефлексией во всю ивановскую), какой тип ей подсунули и что с ним делать. Приходится ей рассказывать.

Ну а stdint.h — это, как и всякий комитетский бастард, сущность дебильная, рушащая концептуальную целостность Си.

Тут вопрос, что вы теряете от попытки. Вроде подаваться одновременно в разные места никто не запрещает.

Хотя, конечно, на ФИИТ поступать не надо, поступайте на основное отделение, и потом постарайтесь не попасть на первый поток — там из вас обезьяну делать будут.

Попробую объяснить.

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

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

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

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

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

Прекрасный пример это ReadKey из модуля CRT. На странице 371, 1 тома показано как её изолировали в процедуру GetKey. GetKey в разы удобнее пользоваться нежели ReadKey, ведь при использовании ReadKey каждый раз при желании обработать пользовательский ввод мы должны помнить, что она может вернуть доп. код и её обязательно нужно вызвать второй раз.

Посмотрите на замечательный кусок кода key := ReadKey, прогуливаясь по коду можно даже не заметить, что здесь символы изымаются из потока ввода, ведь здесь переменной присваивается значение, мы ожидаем только присваивание, а на выходе из буфера изчезла клавиша.

Бывают побочные эффекты в вызовах подпрограмм. Возьмем абстрактную в воздухе подпрограмму f(f1(x), f2(x, y), f3(x, y, z)), и каждая из f1, f2, f3 имеют побочные эффекты, одна добустим изменяем x, и печатает его значение, другая тоже пытается изменить x, у третьей тоже есть свои приколы. Вопрос в каком порядке исполняться побочные эффекты? Измениться ли поведение если включить оптимизации? Хорошо пусть порядок вычислений прямой, теперь попробуйте разгадать в этом случае поведение программы. Хорошо если на это уйдет минут 15.

Вот почему.

Короче говоря функции следует рассматривать, только как функции в математическом смысле (с некоторыми исключениями), а для всего остального есть процедуры.

Дополню ответ Андрея Викторовича:

Сама по себе передача по ссылке (var) не является побочным эффектом, даже если вы используете такую передачу не в процедуре, а в функции. Побочным эффектом являлось бы, например, изменение внутри функции параметра переданного по ссылке, но никак не сама передача.

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

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

Надеюсь теперь стало понятней. =)

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

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

Я считаю, что антивирус не нужен даже под Windows, не только под Linux. Работа антивируса в фоне очень сильно замедляет все операции с файлами, но при этом он всё равно не гарантирует отсутствие вирусов.

Вирусы под линукс теоретически существуют, но в дикой природе наблюдаются лишь в единичных случаях. Если соблюдать простые меры предосторожности, то вы с ними не столкнётесь. Если не соблюдать — скорее всего тоже нет, но гарантии я вам не дам.

Теоретически что-то вроде вирусов для линукса существует.

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

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

В общем, простейшие правила информационной безопасности и можете не беспокоиться:

Если не нужен SSH — отключите демон sshd, если нужен, настройте авторизацию по ключу без пароля или установите сложный пароль. Не помешает перевесить на недефолтный порт, но не обязательно.

Программы старайтесь ставить только из репозитория своего дистрибутива. Если требуется поставить что-то, чего там нет, лучше всего собрать из исходников самому. Если где-то предлагают для установки запустить что-то вроде curl http://something | bash — не делайте этого.

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

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

качал вирусов себе на линух.

Распаковал.

Поставил под root.

Не завелись. Два часа гуглил, оказалось, вместо /usr/local/bin вирусы стали в папку /usr/bin на которую у юзера malware нет прав на запись, поэтому вирус не может создать файл процесса. Нашел на китайском сайте патченый .configure и .make, пересобрал, переустановил.

Вирус заявил, что ему необходима библиотека cmalw-lib-2.0. Оказалось cmalw-lib-2.0 идет под CentOS, а под убунту ее не было. Гуглил два часа, нашел инструкцию как собрать .deb пакет либы из исходников. Собрал, поставил, вирус радостно запустился, пискнул в спикер и сделал core dump.

Час чтения syslog показал, что вирус думал, что у меня ext4 и вызывал ее api для шифрования диска. В btrfs это api deprecated поэтому линукс, заметив это непотребство, перевел раздел в рид-онли.

В сердцах открыл исходники вируса, grep'нул bitcoin кошелек, отправил туда $5 из жалости и пошел спать...

Работая с Linux (в вообще, скажем так, с нормальными системами) с 1994 года, я ни разу не видел ничего даже отдалённо напоминающего вирус. Отказавшись от мелкомягких пародий на операционки, можете про вирусы забыть. И про антивирусы (которые не более чем развод на бабки) тоже.

Ровно там же, где грань между обычной коммуникацией и информационным насилием: в наличии или отсутствии факта навязывания коммуникации. Скажем, книга или сайт сами по себе пропагандой быть не могут, а вот рекламные баннеры, ведущие на сайт, посвящённый некой политической, этической, философской и т.п. точке зрения — это, несомненно, пропаганда; точно так же когда сектанты на улицах раздают свои книженции — это тоже, несомненно, пропаганда (хотя сами по себе книженции и сам по себе сайт как таковой — нет).

А что, это всё не очевидно?

Ещё вот так можно проверять булевские переменные:

bool value;
...
if (value.ToString().Length == 4)
{ 
  ...
}
else if (value.ToString().Length == 5)
{
  ...
}
else
{
   throw new ArgumentException();
   return !true && !false;
}

Это легендарный индусский код, если что. Особенно последнее else впечатляет.

1. У вас какой-то супер странный стиль выбирать идентификаторы, читать сложно.
1) В паскале приняты идентификаторы, где слова набраны с заглавных букв алфавита и без знаков подчеркиваний. Например, first_element следовало бы переписать как FirstElement, а current_element, как CurrentElement. Из Print_All_Numbers_Backwards убрать знаки подчеркиваний, и стало бы PrintAllNumbersBackwards, хотя я бы выбрал другой идентификатор (скажем PrintNumbersInRev(erse)Order), но впринципе придираться не к чему. И дальше.
2) И допустим для вас нормально использовать стиль с подчеркиваниями, тогда почему бы тогда не сохранять единый для них стиль: не current_state, element_ptr и Print_All_Numbers_Backwards, а скажем Current_State, Element_Ptr, Print_All_Numbers_Backwards или всё в нижнем регистре сurrent_state, element_ptr и print_all_numbers_backwards.

current_state = true?
Хочу вас разочаровать, но можно сделать просто и элегантно if current_state then, ещё одна придирка возможно, что current_state здесь выглядит очень странно, может вы бы не стали бы сравнивать логическое выражение (!) (переменную current_state: boolean) с true если бы название было бы более подходящее.

19 строка: {не делать ничего}
Нет нельзя (категорический!) использовать символы не из ASCII в тексте программы, даже в комментариях.

Эм.., вы вообще рабочий код скинули?
74 second := nil;
75 begin
76 first := Read_And_Insert(first, second);

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

Мой вам скромный совет, вернитесь на эту страницу, только когда в тылу будет подчищено. То есть предыдущие части нужно бы с карандашом перечитать. У вас пробелы в самых базовых вещах.

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

Начну с самого главного: в процедуре Is_Your_Data_Correct самым грубейшим образом нарушена расстановка структурных отступов, причём нарушена так, что с первого совсем расфокусированного взгляда даже не видно, в чём косяк. Всё остальное можно как-то там объяснить недостатком понимания происходящего, отсутствием опыта и т.п., но когда оператор if (и вообще любой оператор) пишется с крайней левой позиции — это ничем, кроме абсолютной безалаберности, объяснить нельзя. Да плюс там ещё кириллица в тексте программы, комментарий написан по-русски; это уже вообще полный беспредел. Ну то есть здесь есть ровно два варианта: либо менять своё отношение к происходящему, либо бросать изучение программирования. Выбирайте, что больше нравится.

А ещё — зачем вон те вон begin и end в головной программе? Не те, которые обозначают начало и конец главной части, а те, что внутри, begin после присваиваний, end перед финальным end'ом. Они, конечно, ровно ничего не меняют в происходящем, но зачем они написаны? Чтобы читателя программы взбесить?

Далее по оформлению: вон директива {$I-} у вас стоит так, как будто она имеет отношение только к всё той же процедуре. А это не так, если бы её действие распространялось только на эту одну процедуру, от неё толку бы не было никакого, поскольку, чтобы перехватить обработку ошибок на себя, нужно, чтобы в режиме $I- был откомпилирован оператор read (а не последующая проверка). К счастью, директива-то действует на весь последующий текст, если только её не отменить (не написать {$I+}), так что операторы read у вас скомпилировались именно в том режиме, в каком надо, но вопрос здесь не в этом — вопрос в том, зачем вы её разместили внутри процедуры. "Чтоб никто не догадался"? Или как?

Чтобы завершить обсуждение этой (крайне странной) процедуры, задам ещё один риторический вопрос: а зачем нужен if с пустой (!) веткой then? Что, противоположное условие записать не справились? Ну так, на всякий случай, в Паскале есть операция "не равно", обозначается так: <>. Но если даже этого не знать, то есть ещё операция not, которая любое логическое выражение превращает в его противоположность.

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

Дальше вот имя переменной current_state — ну охренеть какое информативное. В голову тут может прийти что угодно, но только не то, что у вас там в действительности (чётность количества элементов, внесённых в список... ан нет, наоборот: НЕчётность). Самое интересное, что у вас ведь даже нет начального состояния, то есть вот "состояние" какое-то есть, и, значит, должен быть, наверное, какой-то конечный автомат, меняющий состояния, но с какого состояния он начинает работу — не определено. Кстати, это ваше "состояние" может так и остаться неопределённым, если пользователь попадётся вредный и не введёт ни одного числа, сразу нажмёт Ctrl-D. Или на ввод вам подаст файл из одних пробелов. Или вообще пустой. В вашей программе, впрочем, это "пофигу", поскольку тогда будет сугубо всё равно, какой из ваших first/second возвращать, они оба так и будут nil, вот только чтобы об этом догадаться, надо ещё посмотреть, как конкретно у вас эта ваша функция Read_And_Insert вызывается. Т.е. чтобы понять, как будет работать вызываемый, нужно знать устройство вызывающего. Декомпозиция такая декомпозиция.

Кстати, коль скоро обратили внимание на этот if, давайте посмотрим и на его заголовок. Что, очень трудно догадаться, что current_state = true есть всегда то же самое, что просто current_state? Ведь специально же в книге эта бредятина разобрана, см. параграф 2.2.9 (ближе к концу), и даже указана причина — неудачное имя логической переменной. Вот прямо ровно ваш случай. Понятно, конечно, что не вы первый, не вы последний, некоторых персонажей приходится пинать весь их первый курс, чтоб они так не делали, а кому-то не хватает и приходится продолжать их пинать на втором курсе. Потому и в книге на этом специально внимание акцентируется (и, кстати, сильно больше, чем в одном месте!) Но нет, куда там, нам же обязательно надо, чтоб нас в это ткнули.

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

Ах, да, и почему Read_And_Insert так называется? Ну, читать-то она, положим, читает, а куда она чего ВСТАВЛЯЕТ? Она там внутри себя вообще-то (по смыслу) строит список целиком, а не в какую-то уже готовую сущность что-то там "вставляет". Очередное "чтоб никто не догадался".

Теперь плавненько подбираемся к сути, но именно что плавненько. А вот скажите, зачем у этой вашей функции Read_And_Insert аж целых два параметра, если всё равно они оба всегда при её вызове равны nil, и иначе быть не может просто по смыслу? Такими вещами вы запутываете сами себя, и в данном случае, как это скоро станет ясно, запутали вы себя вполне успешно. А всё почему? А всё потому, что не задались вопросом "что делает Read_And_Insert". А это, между прочим, очень важный вопрос, и ответ на него должен состоять из одной простой фразы, и из этой фразы должно быть очевидно, зачем нужны все параметры. Функция эта у вас читает числа и формирует из них список; ради всего святого, накой чёрт для этого нужно — ещё прежде, чем начнём работу — знать адреса аж двух элементов такого списка?!!! Список ещё не сформирован, мы его формировать даже не начинали, а адреса двух его элементов нам вынь да положь? Это вообще как? Это вообще куда?

Теперь поглядим на ваш цикл чтения. Проверили SeekEof, убедились, что "там что-то ещё есть", то есть вроде бы есть что читать. После чего читаем сначала одно число, а потом сразу же другое без всяких проверок. А кто вам сказал, что там два числа есть? Может, там было только одно число и после него больше ничего?

Ну то есть вы числа читаете парами — и без вариантов, хотя сами себя (и читателя программы) тщательно пытаетесь убедить в противоположном. Даже ввели эту вашу current_state, и даже проверяете её. Вот только на выходе из цикла она ни при каких условиях не может оказаться истинной. Внутри цикла — некоторое время истинной остаётся, но потом неизбежно и неотвратимо ей снова присваивают false. Ах да, ещё она может оказаться неопределённой, если цикл ни разу не прокрутится (тот самый случай пустого файла). И в этом случае она совершенно случайно может оказаться истинной (но с тем же успехом может оказаться и ложной, это зависит от того, какой конкретно мусор лежал в стеке до того, как была вызвана ваша функция). А вот если в файле хоть что-то было, то ложь без вариантов. Так что для случая нечётного количества чисел ваша функция работать будет заведомо неправильно.

Самое интересное, что список-то она при этом сформирует. Чтобы понять, что это реально происходит и даже "почти правильно", мне потребовалось минут десять разбираться в вашем теле цикла. Первое впечатление было, что этот сумбур работать не может в принципе. Но нет, оказалось — может. Как-то там. Во всяком случае, в памяти выстраивается односвязный список, в конце таки да — nil, правда в первом элементе может быть ноль, не имеющий отношения к задаче (это если чисел было нечётное количество). Отсюда же, кстати, и необходимость второй раз давить Ctrl-D: первый конец файла у вас read "употребил", а чтобы SeekEof, наконец, false выдал, приходится ещё раз устроить Ctrl-D. Ну да ладно.

Давайте теперь посмотрим, что с этим списком будет происходить дальше. Для начала посмотрим на головную программу. В first будет адрес начала списка. В second так и останется nil вне всякой зависимости от того, что с одноимёнными переменными происходило внутри Read_And_Insert (это же совсем другие переменные, просто имена зачем-то одинаковые — наверное, чтоб читателя программы ещё и тут ввести в заблуждение; впрочем, "перехитрили"-то вы в итоге сами себя).

Ну и добираемся, наконец, до того места, где программа валится с runtime error. Это у нас процедура (спасибо, хоть не функция) Print_All_Numbers_Backwards. Правильный ответ на вопрос "что она делает" должен был бы, наверное, быть таким: "она распечатывает числа из списка". Ффффсё. Никаких "backwards", ведь числа она вообще-то печатает ровно в том порядке, в котором они расположены в списке. И — ещё важнее — для этого ну вот просто ни в какое место не упёрлись ДВА адреса элементов.

Лезем внутрь процедуры. И наблюдаем для начала интересную картину: параметр second вообще никак не используется. Вот вообще. Совсем. На первой же итерации цикла он получает значение, отличное от того, которое было передано, ДО того, как переданное значение будет хоть как-то использовано. Вопрос, зачем тогда передавать параметр (который к тому же взрывает мозг читателя программы вопросом, зачем он нужен).

Дальше — больше: элементы списка печатаются парами. Эй, а вдруг там нечётное количество элементов, тогда как? Впрочем, да, тут эффект чётной ошибки: функция, которая список строит, построить список из нечётного количества элементов не может в принципе. Но если её исправить так, чтобы она всё-таки работала правильно, а не как попало, то она, конечно, будет строить список из такого количества элеметов, сколько пользователь вколотил чисел. И тогда мы тут с этой "печатью парами" пролетим, как фанера над парижем.

Но падает-то она не поэтому. Падает она, потому что так сформулировано условие цикла. Цикл при таком условном выражении будет продолжаться, пока хотя бы один из двух указателей (этих вот first, second) не равен nil. А выйти из цикла программа, соответственно, должна при противоположном условии, то есть когда? Когда ОБА указателя СРАЗУ окажутся нулевыми. Ну так не успеет этого случиться, вот в чём проблема. Сначала получится так, что first уже нулевой, а second пока что нет. Вот тут она и трапнется. Это и есть ответ на вопрос, почему ваша программа вылетает с runtime error 216. Самое занятное, что ЭТО как раз исправить проще пареной репы: в условии оставить только проверку first, и дело сделано. Валиться она после этого перестанет.

А теперь оцените объём получившегося у меня текста, сравните с размером предыдущего абзаца, который отвечает на заданный вами вопрос "чего это она валится", и подумайте, станет ли ваша программа правильной, если вы заставите её больше не валиться. Я бы сказал, что из всего, чего вы тут навертели, вот эта вот мелкая ошибочка, формально приводящая к аварии — это прямо-таки мелочь, не заслуживающая внимания.

UPD: Ваша простыня под заголовком "Так лучше?" раскрыта не будет. Нет, так не лучше, бред как бред, местами, наоборот, хуже стало, причём сильно — вы, по ходу, читать не умеете. И вы уже злоупотребляете моим временем; всё, ваш лимит исчерпан.

Скажем так, из ныне поддерживаемых библиотек виджетов я умею работать с двумя — FLTK и WxWidgets. После освоения FLTK я к WxWidgets не имею желания прикасаться. Т.е. если вас интересует, на чём я буду писать GUI, когда в очередной раз придётся это делать, то ответ однозначный: да, на FLTK. Просто при этом я, пожалуй, всё же не стану утверждать, что все остальные библиотеки виджетов вот прямо совсем ни на что не годны. Просто лично я на них писать не буду, но я не скажу, что каждый, кто пишет, скажем, на Qt, прям сразу круглый дурак.

А вот для обучения — тут, извините, без вариантов, учить больше не на чем, все остальные мозг изуродуют.

Когда всё таки нужна многопоточность: Dataflow architecture.

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

Правда меня напугало вот это "Dataflow architectures have no program counter, in concept: the executability and execution of instructions is solely determined based on the availability of input arguments to the instructions,[1] so that the order of instruction execution is unpredictable, i.e., behavior is nondeterministic.".

Быстро посмотреть там оно на 51:50.

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

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

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

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

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

Обобщая: многопоточность не нужна вообще ни для чего.

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

Вы что, издеваетесь?

Во-первых, под Windows крайне затруднена манипуляция полновесными процессами, там только мультитрединг фактически и есть (и это не повод его использовать, это повод никогда не писать ничего серьёзного для Windows). Во-вторых, я не в курсе виндовой конкретики (когда я последний раз писал под Win/*, это была ещё "платформа" Win16, больше четверти века назад), но в системе обязана существовать штатная возможность избежать подобных "пауз" — сначала заказать исполнение действия, потом через какое-то время проверить, завершилось оно или нет, и в нормальных системах такая возможность, разумеется, всегда есть. Если конкретно под виндой её нет — я не слишком удивлюсь, под виндой вообще много чего нет.

Во-вторых, "решение" такой проблемы через треды только выглядит простым (как, собственно, и всё, что связано с тредами). Между прочим, еле нашёл нужное место в тексте по вашей ссылке, там собственно самого этого решения нет, есть только ссылка на его описание "как это сделано в mercurial", ну я mercurial никогда не использовал и, надеюсь, никогда не буду, поскольку, когда людям приходят в голову такие "решения", их софт становится просто опасен. И не вполне понятно, считает ли автор статьи такое решение допустимым.

Зато в статье по вашей ссылке есть одна интересная фраза — последняя. Вот она:

Please don't cargo cult my advice without measuring and applying critical thinking first.

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

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

В общем, я его пробовал — фигня:

1. Написано на .NET и в линуксе работает через пень-колоду. Никаких дополительных модулей нет, только консольный ввод-вывод. IDE вообще не работает.
2. Следует из 1: криво реализованы указатели. Поддерживаются не все операции, какие поддерживаются могут работать неправильно.
3. Плохая совместимость с полноценным паскалем. Например нету ReadStr.
4. Хоть код и открытый, но он кривой, завязанный на MS Visual Studio и прочую проприетарщину.

В общем выкиньте каку и возьмите хотя бы Free Pascal. Тоже не супер-идеал, но хотя бы работает и достаточно неплохо.

А что, не очевидно, что именно я по поводу этого дерьма могу думать и по каким конкретно причинам?

Я предлагаю следующие шаги:

1. Выберите задачу своей последней программы -- лучше если это будет что-то в духе системы слежки или социального кредита, можно построить систему отслеживания и контроля передвижения людей -- одним словом, нужно выбрать такую тему, за которую счастливые пользователи вас не просто по головке погладят, а сделают это с такой радостью, что у людей с не титановым черепом голова могла бы пропасть по причине стирания;
2. Установить винду последней версии и использовать для программирования только её;
3. Программировать только на Rust, ведь все программы должны быть записаны на лучшем языке на свете;
4. Так как Rust -- это не просто лучший язык на свете, но лучший язык низкого уровня -- писать надо именно низкоуровневую программу;
5. Разумеется, делать это надо используя всю полноту достижений человечества в лице самых современных процессоров, обладающих такой привлекательной величиной в тысячи и десятки тысяч страниц невероятно приятного к чтению, осмысленного текста документации;
6. Использовать при программировании все доступные методологии и лучшие практики написания кода, как если бы дядюшка Боб в вас вселился;
7. Наконец я предлагаю вам показать, что полученная программа не имеет ошибок, лучшим методом известным человечеству -- путём всестороннего её тестирования -- это займёт у вас некоторое время, зато по его истечении вы сможете наслаждаться полным покоем во вселенной пережившей тепловую смерть.

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

P.S. Самое страшное, что смотря на этот список я понимаю, что таки в этом мире есть люди, которые подобным и правда занимаются.

С этим вопросом вам куда-то сюда.

Подробный ответ на этот вопрос содержится в третьем ("напутственном") предисловии в первом томе книги Программирование: введение в профессию.

Читая "Программирование. Введение в профессию", возник вопрос

"Подъезжая к станции, с меня слетела шляпа". См., например, тут. Аккуратнее с деепричастными оборотами.

По существу вопроса: см. Оформление программного кода, во втором издании это пар. 1.2.1 (стр.10 в книжке, 12-я в pdf-файле).

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

А вот чтобы хорошо писать программы надо хорошо программировать (тавтология, ага), но научиться этому простым повторением и подражанием нельзя. Пишите свои программы и думайте о них -- удачи вам!

P.S. Конечно и просматривать чужой код тоже очень полезно, но не в целях подражания для развития своего стиля или навыка написания программ, а в целях развития навыков чтения кода.

P.P.S. Ещё отмечу, что в самом начале обучения программированию подражание примерам (простым и маленьким!) разумно -- вот только если вы способны читать гнутый код (совсем не простой и не маленький), то этот этап уже давно пройден. (Если не способны -- и не надо его читать, не торопитесь и решайте небольшие задачи.)

Код от GNU -- далеко не лучший пример для подражания. Да и вообще, говнокода (вполне рабочего, и даже от известных людей/проектов) в опенсорсе более чем достаточно, так что примеры для подражания нужно выбирать очень осторожно.

К совету посмотреть код от OpenBSD присоединяюсь, кстати.

В качестве примера для подражания могу посоветовать проект OpenBSD.

Что-с? Это гнутые-то "код лучших и примеры для подражания"? Вы видели, как они исходники оформляют, пардон? Они бы мне не просто зачёт не сдали, там всё хуже: я обычно, видя безграмотное оформление кода, отказываюсь этот код обсуждать в принципе; ну так вот любой гнушник — во всяком случае, такой, который в этом кодингстайле реально пишет, а не конвертирует в него исходники программами вроде indent — на моём зачёте засыпался бы ровно на этой стадии.

Что у вас за бардак в голове?! Какие ещё "системные вызовы" у консоли, какая разница, на чём они написаны (вообще-то ни на чём, никаких таких системных вызовов не существует в природе, но если бы они даже существовали и были бы написаны на Си, это ничему бы не мешало).

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

Кстати, вот это ваше "неужели получилось" впечатляет особенно. Free Pascal предусматривает линковку с модулями, написанными на других языках, и вызовы подпрограмм в соответствии с разными конвенциями, в том числе, таки да, и с сишной тоже, то есть взять модуль, написанный на Си, включить в сборку паскалевской программы и вызывать из неё функции, в том модуле описанные — это абсолютно штатная возможность, присутствовавшая во Free Pascal с самого начала (и, насколько я помню, в Turbo Pascal она тоже была). UPD: если интересно см. https://www.freepascal.org/docs-html/prog/progsu46.html - тут пример, как целиком библиотеку подцепить, есть ещё директива {$L} — она цепляет отдельный объектник; функция описывается и используется точно так же.
Но и это здесь к делу не относится — если я только правильно понимаю, как устроено это чудище внутри, использования кода на языках, отличных от Паскаля, авторы FP избегают. В общем, нет там ни сишного кода, ни обращений к таковому.

Для системных вызовов (настоящих, блин, реальных, а не выдуманных вами) у FP RTL есть свои собственные обёртки, выполненные, естественно, в виде ассемблерных вставок — точно так, как это сделано и в libc. Сие обстоятельство никакого отношения не имеет к реализации именно модуля crt, поскольку любая программа, работающая под управлением ОС, вынуждена общаться с внешним миром именно через ОС, т.е. через те самые системные вызовы. Любая, понимаете? Даже просто чтобы корректно завершиться, нужен системный вызов. Самая короткая программа на Паскале, как известно, вот такая: «begin end.» — никаким модулем crt тут и не пахнет, а системный вызов — да, нужен, прямо-таки необходим.

Ну а экран управляется esc-последовательностями. Тут всё совсем просто.

Дайте-ка угадаю... программа многомодульная? :-)

Есть, и не радует совершенно. Всего было 548 скачиваний, из них успешных (читай -- до конца файла) всего 104, остальные 444 обрывались раньше. Это всё суммарно по всем трём выложенным файлам.

Придётся, видимо, расстаться с остатками веры в человечество.

Так-с... у меня возник вопрос, вы понимаете, что модуль может зависеть от другого на уровне интерфейса, а может — на уровне реализации? Перекрёстная зависимость на уровне интерфейсов невозможна (то самое "не скомпилируется"), но зависеть крест-накрест на уровне реализаций модули могут, имеют право, никак это компиляции не мешает. На Паскале это uses в секции implementation (не interface!), на Си это #include из файла реализации (но не из хидера). Не так чтоб это было хорошо и правильно, но предметные области сплошь и рядом заставляют так делать, и никто пока не умер.

https://habr.com/ru/company/otus/blog/575954/

Очередной удачный теракт

Мне кажется, что я понимаю, как этот новый язык должен выглядеть; некоторые соображения на эту тему можно прочитать в последней главе третьего тома Введения в профессию. К сожалению, я совершенно не уверен, что смогу состряпать сколько-нибудь пристойный компилятор за сколько-нибудь приемлемое время.