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

Re: Кодогенерация в Си

> ещё нет конструкции

С чего бы это вы так уверены?

crocodil@trex:~/work/misc$ cat xx.c
#include <stdio.h>
#define J(x, y)  (x##y)
int main()
{
    int a7 = 49, a15 = 225;
    printf("%d %d\n", J(a, 7), J(a, 15));
    return 0;
}
crocodil@trex:~/work/misc$ gcc -ansi -pedantic xx.c
crocodil@trex:~/work/misc$ ./a.out 
49 225
crocodil@trex:~/work/misc$ 

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

> как писать шаблоны на Си?

мой ответ в любом случае совершенно однозначен: никак. Независимо от того, возможно это или нет.

> раньше это решали кодогенерацией

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

> Как это предпочитаете делать Вы?

Ну, ответ очевиден, но на всякий случай повторю: никак.

> GNU Autogen, но никогда не пробовал

И не пробуйте. Пожалейте тех, кому ваше изделие придётся собирать.

Re: Антинатализм

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

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

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

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

Re: Книги

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

Re: Что почитать из Лема

Вообще, конечно, путь у каждого свой, но раз уж спросили — попробую ответить.

Начните с рассказов, сборники "Кибериада", "Сказки роботов", "Звёздные дневники Ийона Тихого", "Рассказы о пилоте Пирксе". Из более крупной формы — ну, "Непобедимый", например. Потом уже, пожалуй, в любом порядке "Осмотр на месте", "Дознание", "Футурологический конгресс", да тот же "Солярис", в принципе. Ну и где-то тут "Возвращение со звёзд". Можно и раньше. А уже после них — "Мнимая величина", "Абсолютная пустота", ну и "Больница преображений" (на всякий случай: это вообще не фантастика).

А вообще, честно говоря, фигня это всё, просто берите всё, что под руку попадётся, и читайте. Лем стоит потраченного на него времени.

Re: Текстовый интерфейс

Сугубо учебным материалом я считаю только то, что в первом томе. Что касается ncurses, то с её использованием написано чуть менее чем всё, что работает в терминале "на весь экран". Ну то есть не всё, конечно, контрпримеры найти можно, но это надо специально искать.

Re: Книги по Linux/Unix

Честно говоря, вопрос не вполне понятен. Достаточно для чего? Для программирования в ядре, конечно, не достаточно. Для построения датацентров тоже, наверное, недостаточно. Да даже для написания программ с GUI недостаточно, хотя тут третий том, возможно, спасёт :-)

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

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

Re: Книги по Linux/Unix

https://download.freebsd.org/doc/en/books/handbook/handbook_en.pdf

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

Re: Книги по Linux/Unix

Установите себе Slackware, и в Интернете можно найти руководство, книжку по Slackware. Кроме книг и документации в Интернете, в самой Slackware есть документация в /usr/doc/. По мне, это - хороший способ именно изучить Линукс.

Re: Книги по Linux/Unix

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

Re: FAQ. Многопоточное программирование

Так? Или какое-то другое ещё?

Re: Объективная реальность математики?

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

Re: Объективная реальность математики?

> Так всё-таки была арифметика изобретена или открыта?

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

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

Скажем, например, слово "кошка". О чём идёт речь? О домашней кошке, о тигре, об абордажной кошке, об альпинистской или какой-нибудь ещё? И в естественных языках эта проблема НЕРЕШАЕМА принципиально. И единственный доступный людям способ её хоть как-то сводить к приемлемой, оставаясь в рамках своего языка - обыкновенная информационная избыточность. То есть говорить вместо "кошка" нечто вроде "животное ко́шка, на латыни называемое felis catus, живущее вместе с человеком, вес 3 килограмма, зовут Юлей". Но здесь моментально возникает проблема масштаба: устранив (и то не до конца) неоднозначность понятия "кошка", мы ввели гору других понятий. Что такое "латынь"? Что такое "человек"? Что такое "килограмм"?

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

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

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

Или, например, можно взять историю Марджори Райс: https://en.wikipedia.org/wiki/Marjorie_Rice Её пример показателен тем, что для своего открытия она буквально изобрела собственный формализм, так как не обладала знанием общепринятой академической записи. Да, весьма запутанный и кривой. Но всё же формализм. Исключение самой возможности думать не в ту сторону. Сюда же можно отнести и математические нотации прошлого: https://en.wikipedia.org/wiki/History_of_mathematical_notation

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

Слишком тупо

Тут существенно больше одной ошибки, просто решето. Начать вот с этого:

> Считается, что бог совершенный

Первая ошибка — вот в этом слове "считается", точнее, в вашем толковании такового. Что значит "считается"? Поскольку ни из чего внешнего это не следует, сие есть предположение. Т.е. в действительности тут говорится следующее: "Предположим, существует бог, т.е. нечто обладающее всеми положительными свойствами. Тогда бог существует". Если выкинуть конкретику, тут имеет место "Пусть существует A. Тогда существует A." Обыкновенная тавтология.

Дальше как в старом мультике: "-- Не хочу идти к кактусу, он колючий! -- Допустим, он не колючий. -- Нет, не допустим!"

Но это далеко не всё. Что такое "положительные свойства"? Вот вам парочка примеров from the real life: скажем, быть патриотом — положительное свойство? Между прочим, большинство людей считает, что да, а я вот считаю, что патриотам, причём вне зависимости от национальной принадлежности, место за пятью решётками, а лучше вообще в гробу, поскольку это именно от патриотов и войны, и терроризм. Или вот вам другой пример: "быть китайцем" — положительное свойство? Тут я свой ответ оставлю при себе :-)

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

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

Короче, это называется гуманитарщина в плохом смысле слова: заведомая чушь, облечённая в "умные" (на самом деле просто непонятные) слова и рассчитанная на публику, не умеющую думать.

Re: Оконные менеджеры

Я использую fvwm2, но публике обычно рекомендую IceWM. Кстати, в книге об этом сказано.

Re: Как относитесь к патентам?

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

Короче говоря, просто один из тысяч вариантов государственного беспредела на ровном месте.

Re: Арифмометр Паскаля

> вводит 99925

Чушь какая-то. Я не могу себе представить арифметическую схему, в которой 99925 имело бы какое-то отношение к числу 25.

Re: Обучение детей и подростков арифметике

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

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

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

Re: Обучение детей и подростков арифметике

Что делать? Устроить его к себе на предприятие уборщиком. Зарплату не выплачивать - он всё равно считать не умеет, даже наверное и не поймёт, что что-то не так. Выгодно!

Re: Целесообразность оптимизации кода

Э-мммм, что-с?!

a = b * (a > b) + a * (a <= b);

За такое программирование убивать надо. Ну то есть если руководитель разработки, увидев ТАКОЕ в коде, этого любителя оптимизаций не уволит к чёртовой матери, то разве что от полной безысходности.

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

А если оптимизацию в компиляторе включить, то, опять же, что-то я сомневаюсь, что он вот это вот выражение осилит. Хотя тут я, пожалуй, не поручусь, то есть надо смотреть. Если осилит, то оно в итоге превратится в тот же if :-)

Есличо, gcc -S знаете? :) можете сами на досуге посмотреть, что там получится в том и в другом случае, как с оптимизацией, так и без.

кроме рекомендаций по оптимизации, нам советовали использовать STL, многопоточность и не соваться в ассемблер

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

P.S. Я ваш тэг code поменял на pre, ибо code делает совершенно не то.

Не издевайтесь над людьми

Представьте себе лицо человека, который увидит выражение a = b * (a > b) + a * (a <= b);. А потом его лицо, когда выяснится, что это на самом деле if(a > b) a = b;. А также сколько времени потребуется потерять, чтобы понять, что тут к чему :-)

Книжка

Кстати, про недопустимость подобных выражений упомянуто во втором издании "Введения в профессию": том 2, страница 48.

Re: Целесообразность оптимизации кода

Да... Вот и "реформа" образования, точнее её "результаты".

Re: Целесообразность оптимизации кода

Если мы говорим про x86_64, то gcc может, по меньшей мере, преобразовать условный оператор в 'cmp rax, rdx; cmovge rax, rdx'. Это примерно 2 такта и должно быть близко к оптимуму.

Re: Обучение детей и подростков обращению с компьютером

Ну для начала: про Scratch забудьте как страшный сон, про Arduino тем более — там на выходе обезьянка получается, причём не только программистская, но и схемотехническая.

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

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

Re: OpenBSD всё?

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

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

Re: OpenBSD всё?

с лора притащил? оно не может быть "всё" тк тупо аналогов нет сходу назови систему в которой из коробки не будет network manager'a, systemd (в тч его огрызков), pulseaudio, dbus, avahi, openssl, sudo, python'a(удаление которого может привести систему в нерабочее состояние), apparmor'a (который любят добавлять, но не писать для него правила) и тд и тп openbsd не учит плохому в отличие от линукса, в коем, чтобы понять, что есть плохо, а что есть хорошо, надо попользоваться и быть любознательным. это особенно весело на начальных этапах, где даже гайдлайны для нубов учат плохому. в openbsd гайдлайны не нужны вся актуальная документация находится в системе

Re: Дырявые интерпретаторы

Нет, тут очевидная практика.

Re: Изучение первого тома

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

• из математической главы — параграфы 1.3.1 — 1.3.3, без этого могут возникнуть проблемы даже просто при формулировке условий всяких циклов и ветвлений;
• из главы "Программы и данные" — как минимум параграфы 1.4.6 и 1.4.7, чтобы не тыкаться потом вслепую куда попало.

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

Re: Сообщения об ошибках в книге

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

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

Re: проект "infoviolence"

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

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

Ну и, конечно, традиционный вопрос в таких случаях: на infoviolence.org вообще-то есть своя гостевая книга, почему обязательно надо сюда постить оффтопик?

Re: проект "infoviolence"

>стриминговых сервисах?

чем mpv --no-video http://infoviolence.org/ru/vblog/v720view/infoviolence_060.mp4 не стриминговый сервис? сайт через консольный браузер открывается

Re: Проектирование программных комплексов

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

Re: Проектирование программных комплексов

На практике сейчас "Проектирование программных комплексов" называют "Архитектурой решений" (Solution Architecture), под это есть отдельные должности "Архитектора решений". Часто слово "решений" опускается и в вакансиях можно видеть позиции "архитектора" - это оно.

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

Из литературы могу посоветовать "Software Architecture in Practice" от Басса, Клементса и Казмана - PDF можно найти в поисковиках. Книжка почти не дает практически применимых навыков, но позволяет открыть для себя новую парадигму мышления.

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

Re: Математические символы

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

Re: Математические символы

На сайте dxdy.ru для ввода математики используют ЛаТех. Вот как они его прикрутили, я не знаю (не специалист).

Re: Математические символы

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

Re: Математические символы

Вообще, есть такая штука как MathML. https://en.wikipedia.org/wiki/MathML

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

Re: Библиотека C++ "на все случаи жизни"

Ага, ну конечно.

STL сделали, херня получилась.

Boost сделали, херня получилась.

Надо ещё что-нибудь сделать.

Когда в третий раз херня получится, пойдёте на четвёртый круг? Или всё-таки остановитесь? Хотя вряд ли, конечно, такие не останавливаются. Some people never learn.

Какого чёрта таких персонажей вообще тянет на мой сайт, а?

UPD: Слушай, сделай одолжение, свали отсюда, а? Мне с такими как ты обсуждать нечего, и если тебе непонятно, что сам этот подход заведомо ублюдочен — то я, извини, тебе ничего нового не объясню. Набьёшь шишек сам, авось допрёт.

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

Re: Библиотека C++ "на все случаи жизни"

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

Re: Мечтать не вредно

> в предверии

Гм, пред-верие... Это как, ещё не верю, но вот-вот поверю? Достали уже, следите за тем, что печатаете. Если что, из контекста тут должно быть скорее "преддверие", но...

> последних событий

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

> то что с ними делать?

Если они не являются гражданами одного с вами государства, то ответ очевиден: уничтожать.

Если являются, то да, вопросы к государству. Впрочем, если оно почему-то не справляется, то останется тоже только уничтожать. Но оно, как ни странно, обычно справляется. Которые не справляются — перестают существовать как государства, превращаются в failed state.

> Можно отгородиться?

Нельзя. В смысле можно, но бесполезно, всё равно прорвёт.

> самое адекватное - вооружаться самому

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

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

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

Re: есть мнение ?

А никак. Есть намного лучше и втрое короче.

Re: GNU Readline

Подозреваю, что это было тупо первое, что в голову пришло. Иного объяснения этому чудовищному решению у меня нет.

Re: Кратенькая история UNIX в начале четвёртой части Учебника

Честно? Да хрен его знает, я сейчас за давностью лет даже не вспомню, откуда я это утверждение выкопал, впервые оно появляется в книжке 2006 года, то есть писал я первую версию этого текста 18 лет назад.

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

P.S. поменял в вашем комменте тэги code на pre, ибо code делает совершенно не это.

Re: Архив гостевой

В смысле "теперь"? Раньше тоже можно было, ровно с момента перехода на новый движок.

Об одном популярном мифе и его последствиях

Конечно, плотность грубейших косяков в этом коротеньком тексте способна удивить сама по себе. Начать с того, что работу с адресами и указателями ТС обзывает "работой с памятью" (если что, с памятью работает вообще любая программа на любом языке). Ещё ТС неявно отождествляет системное программирование с работой на языке ассемблера, что уже просто кромешная чушь. А кроме того — выражает надежду, что можно придумать язык, который "работал бы так же быстро как С", хотя как раз скорость работы тут сто лет не главное, и вообще это не характеристика языка как такового, тормозную программу можно написать на любом языке, не исключая языков ассемблера; и если программа тормозит, то виноват (всегда!) не язык, а автор программы. Но это всё, как ни странно, не так уж важно.

Более интересное мифотворчество начинается с утверждения, что эта вот, в терминологии автора коммента, "работа с памятью" якобы представляет собой "просто лишнее усложнение". Делается даже заявление, что-де "все стремятся" присваивать переменные структурного типа вместо явного вызова memcpy. Ага, вот прямо все. Не знаю, кто такие эти "все" и где ТС их откопал, но лично я не припомню, когда в последний раз видел присваивание переменных структурного типа, передачу их по значению в функции или возврат их из функций в качестве значения в программах на чистом Си. В C++ — сколько угодно, но это совершенно другой язык с другими традициями (дополнительное пояснение см.ниже); если же такое встречается в коде на чистом Си — это довольно явный признак профнепригодности или как минимум полного непонимания, что такое этот самый чистый Си и зачем он нужен.

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

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

Между прочим, языки, в которых динамическая память, как выразился ТС, является "фундаментальными конструкциями языка", давно уже придуманы, можно ничего нового не городить. Вся скриптуха, например, именно такова. Лиспы там всякие, опять же. Да и вообще всё, кроме тех языков, с которыми хоть как-то ещё можно работать в качестве языков общего назначения (а таких я знаю ровно два: чистый Си и C++, оба ужасны, оба сделаны чёрт-те как, но всё остальное вообще никуда не годится).

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

Пожалуй, здесь я не откажу себе в удовольствии процитировать самого себя (см. третий том, пар. 9.3.3 "Два подхода к сравнению языков"):

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

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

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

Хотя мы, по правде говоря, не знаем, пытается ли этот субъект, скрывшийся под сакраментальным именем "Anonymous", программировать; возможно, он как раз из тех самых преподов-халтурщиков. По стилю, во всяком случае, похоже. Честно говоря, очень хочется им всем посоветовать пойти утопиться, но тут есть одна сложность: если все, кто преподаёт программистские предметы, не умея при этом программировать, разом самовыпилятся, вести программистские предметы в учебных заведениях всех уровней станет просто некому, оставшихся считанных единиц действующих или хотя бы бывших программистов на всех не хватит никак. Увы, реальность именно такова. Но есть одна фраза, от которой я в отношении этой публики точно не откажусь: не знаешь предмета, который преподаёшь — хотя бы не лезь в методисты.

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

Re: Грязные хаки с памятью

Даже на чистом Си, где работа с памятью неизбежна все стремятся с ней по возможности не работать.

Вас обманули.

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

Это просто какой-то позор... Какая-то нездоровая тенденция "упростите мне жизнь донельзя, чтобы я "программировал" местом, на котором сижу и не включал мозг". С какого бодуна выпускнику говнокурсов (судя по контексту коммента), который, вероятно, до этого работал каким-нибудь продавцом-консультантом, должны создавать какой-то инструмент под его глупые запросы? От этого коммента вообще отдаёт какой-то наглостью: неосилятор сетует, что ему не сделали очередной нескучный и несложный язычёк "шоб работа с памятью меня не напрягала". Так есть питон и жаба - в чём проблема? Или тенденция последних лет "вылета на мороз" всяких принеси-подай от IT напугала? Тут, походу, типичные страдания "случайного попаданца", который решил попробовать в серьёзное программироваие и сдулся, потому что "сложно работать с памятью".

Может резко, но реально задолбали эти страдания "сложна работать с памятью". Сложно, ну иди в доставку еды или ещё куда.