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

Re: Free Pascal и uses sysutils

Строго говоря, sysutils — это не библиотека, это модуль (unit), а библиотека — это набор из модулей.

Пользоваться CreateDir'ом в принципе можно, никто вас за это не убьёт; а чем вас не устраивает mkdir из модуля system? Очень хочется лишний модуль подключить?

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

Re: Wayland

Если интересно моё мнение — wayland не имеет права на существование.

Re: elogind

Команды выше недостаточно, поскольку еще есть пакеты libelogind0 и libelogind-compat. При попытке их удалить, apt предлагает удалить xorg, atril и много чего еще, поэтому на этом мои попытки убрать elogind лобовым способом заканчиваются (надеюсь, кто-то из посетителей сайта сможет предложить способ получше).

Re: Что-то книжки не качаются

Вот буквально только что проверил wget'ом, всё нормально качается.

Re: Что-то книжки не качаются

> Многоточие в конце не мое, а wget'а

Рекомендую обратить внимание на тег pre :)

Re: Средство обмена мгновенными сообщениями

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

Ну а дальше

> Что если разработать такой протокол, который будет простым, как SIP SIMPLE

Вы вообще о чём? SIP? Простой? Вы уху ели?

Касаемо конкретного вопроса об IM, у меня на эту тему давно есть понимание, как это должно выглядеть. За основу я намерен взять SMTP, причём на уровне rfc двухтысячных номеров, всё что было позже — игнорировать всем скопом. Даже из электронной почты образца конца девяностых есть что повыбрасывать, например MIME (вплоть до reject'а писем, содержащих что-то отличное от plain text, сразу после получения заголовка), для передачи небольших файлов использовать uuencode, большие файлы вообще не пересылать по этому протоколу. Разрешить на усмотрение реализаторов smtp extensions, при этом наложить требование о корректной работе с каждым, кто эти расширения не поддерживает (в особенности это касается STARTTLS; про себя могу сказать, что если что-то из этого буду делать сам, TLS там не будет).

На основе такого обрезанного SMTP сделать протокол обмена сообщениями, отличающийся от оригинала, во-первых, заменой понятия final delivery на понятие message collection (NB: примерами такой collection можно считать и почтовую очередь, и почтовый ящик, и какой-нибудь архив списка рассылки, ну то есть вообще любой набор сообщений, хранящихся в одном месте; изначально предполагать, что передача сообщения из одной коллекции в другую может потребоваться вообще когда угодно, например для создания копии коллекции в другом месте); во-вторых, предположить, между некоторыми из узлов, поддерживающих этот протокол, будет идти плотный трафик в обе стороны, так что соединение, во-первых, следует воспринимать как потенциально-постоянное (а не на одно сообщение), и, во-вторых, что там в любой момент может потребоваться поменять местами клиент и сервер (в SMTP это называется команда TURN, её сделать обязательной, плюс добавить асинхронный ответный код вроде 492 please turn (таким способом сервер будет сообщать клиенту, что сам хочет стать клиентом, после этого клиент имеет право передать ещё одно сообщение, но не больше, и после этого — либо сразу, если передавать нечего -- должен как раз таки дать команду TURN). Ну и плюс к этому изначально предполагать, что узлы сети, построенной на этом протоколе, бывают двух видов: перманентные и "клиентские" (название условное). Эти вторый принципиально отличаются от первых тем, что с ними соединение установить невозможно, типа, их не зовут, они сами приходят; для них предусмотреть какие-то способы объяснить, что они реально те, за кого себя выдают (возможно, отдать конкретику на откуп реализациям).

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

С обычным SMTP эта штука будет потенциально совместима, что позволит использовать то же пространство адресов, что и в обычной почте. Можно даже, например, MIME'овые сообщения не режектить, а принимать и сразу отдавать кому-то, кто с ними умеет обращаться (например, "обычному" smtp-серверу, висящему рядом на другом номере порта).

Иной вопрос, что то, что я писал на тему средства общения, неподконтрольному никому — это было не про обмен сообщениями, а про наложенную сеть IPv6 over UDP. Другой уровень. Сообщениями в такой сети можно обмениваться как угодно.

Re: Телеграм

Мой ответ вам прекрасно известен, зачем задавать этот вопрос? Телеграм не подлежит использованию ни при каких условиях, то есть просто нельзя и всё. Точка.

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

И вот уж чего я тут в упор не вижу, так это "неразрешимой проблемы". Даже просто проблемы как таковой.

Re: Браузеры

Я использую palemoon, но это чисто от безысходности. Хороших браузеров в природе не существует, точнее, те, которые существуют, не откроют 99% сайтов.

> Firefox из коробки. Я не уверен что он сильно лучше тех же Яндекс или Хрома.

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

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

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

И ещё:

> по-моему дилетантскому мнению

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

Re: Браузеры

1. Все мейнстримные браузеры и весь мейнстримный веб -- дополняющее друг друга говно.
2. Яндекс-браузер и хром -- переполненное зондами говно.
3. Chromium и firefox -- опенсорсное говно с зондами, из которого, приложив недюжинные ассенизаторские усилия, можно попытаться отчерпать некоторое количество зондов.
4. Ungoogled-chromium, iridium, librewolf и т.п. -- ассенизаторские проекты с заявленной целью вычерпать зонды из firefox или chromium.
5. Отдельно хочу отметить, что в OpenBSD chromium, iridium и ungoogled-chromium обложены по самое нехочу патчами, которые запрещают доступ к большей части файловой системы и многим системным вызовам. Firefox и firefox-esr тоже, хотя там, говорят, сложнее разделять права в силу более монолитного дизайна.

Re: Браузеры

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

Re: менторинг

Вроде бы никто из действующих участников пока уходить не собирается.

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

Re: xz

>А кто его туда добавил?

>Jia Tan

Китаец, либо кто-то хочет заставить думать, что это был китаец.

Re: Аудио сервер в Linux

У меня основной дистрибутив всё ещё Devuan, там systemd нет, но pulseaudio есть и, увы, elogind тоже есть. Специально я вопрос с аудио не изучал. От pulseaudio есть одна польза — сетевая прозрачность, т.е. если на удалённой машине через ssh -X запустить очередное "приложение", которое рисует окошки и издаёт звуки, то эти звуки можно услышать локально. Срабатывает, надо сказать, не всегда, управлению, я бы сказал, вообще не поддаётся, т.е. pulseaudio — это какой-то, натурально, гроб с музыкой. Собственно, как и всё, к чему поттеринг щупальца приложил.

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

Re: Аудио сервер в Linux

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

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

Re: Аудио сервер в Linux

Побуду адвокатом дьявола: во-первых, pulseaudio не требует наличия elogind. Во-вторых, pipewire не требует ни elogind, ни dbus, хотя для отключения dbus надо отредактировать конфигурацию.

Re: Ютуб

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

Re: Работа системным администратором

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

Да и вообще, в принципе тот же nginx ничем не плох сам по себе, если хотите работать сисадмином — рано или поздно с ним всё равно столкнётесь, софтина как софтина. MySQL осваивается без особых проблем, если от вас не требуется самому запросы писать (если требуется, то тут сложнее, DBA — это в целом отдельная квалификация).

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

Re: riscv и свободные архитектуры

> Важна ли, по Вашему мнению, открытость железа?

Конечно, важна. А что, тут есть какие-то сомнения?

> в сторону отказа от авторского права

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

> RISC-V

Не знаю, не изучал вопрос.

> до создания комитетов по стандартизации

А что, есть какие-то стандарты процессоров? Или систем команд? Вот то есть не спецификации, а именно чтобы стандарты, "принятые" комитетами?

Re: Гостевуха по топикам

> Будет гостевая книга по топикам?

Это как? Каждое поддерево на отдельную страницу? В принципе думал про такое, но пока есть дела более высокого приоритета.

> Браузер аж надрывается

Не наблюдаю эффекта. Только что для прикола открыл эту страничку на нетбуке lenovo s10 (двухъядерный 32-битный (!) процессор, 2Gb оперативки), браузер palemoon. Даже не чихнул, собака.

Re: Гостевуха по топикам

> Браузер аж надрывается

Прямо даже любопытно. Не могли бы вы описать параметры системы, где это происходит? Что за браузер, что за ОС, что за железо?

Re: Гостевуха по топикам

Может, javascript в браузере enabled?

Re: Мейнстримные дистрибутивы

Я в целом и не утверждал, что попсовые дистры не нужны. Но вот, пардон, elogind с его файловыми системами /run/user/UID на каждого активного юзера — не нужен вне всякой зависимости от степени попсовости дистра.

Re: sed & awk

sed я использую, но сильно не весь — только когда понимаю, что мне предстоит в куче файлов проделать одну и ту же контекстную замену, которую я понимаю, как сделать одной командой в vim'е. У sed'а почти тот же синтаксис для этого, т.е. мне для этого не нужно ничего дополнительного знать.

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

Честно говоря, когда что-то серьёзное надо сделать с текстами, мне проще написать что-нибудь на C++.

Re: Как без JS сделать просмотр видео на сайте?

Вы не поверите, там просто файлы. Вот буквально файлы. Формата mp4. Если просто положить на сайт такой файл и дать на него ссылку, будет именно так, "как у меня на сайте".

Различие между двумя кнопками только в том, что по ссылке "скачать" файл отдаётся с типом application/octet-stream и ещё там заголовочек Content-Disposition добавляется, т.е. там в директории лежит .htaccess вот такой:

AddType application/octet-stream .mp4
Header set "Content-Disposition" "attachment"

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

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

Фигассе крик души :-)

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

Re: Брр, указатели

Мне помогло написание программы с использованием рекурсии. Почему-то так понятнее чем через цикл, но после этого можно перейти и к циклу.

Re: Брр, указатели

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

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

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

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

1) Ещё раз то, что было в моем изначальном комментарии: лучше не лезьте в объяснения задач до того, как решите их сами. Автор не шутит, когда рекомендует это (поразительно, кто бы мог подумать!); если же всё-таки вы решили туда залезть раньше времени, постарайтесь хотя бы не читать написанный код и ограничиться словесным описанием алгоритма и картинками-схемами. У меня чтение кода до того, как я его понял, дало самый неприятный результат - на некоторое время парализовало способность думать над решением задачи: поскольку я уже запомнил решение, я не мог сам до него дойти методом проб и ошибок, и, как следствие, до конца его понять;

2) Если вы всё-таки залезли в объяснения до того, как всё поняли, то, возможно, нет худа без добра - у вас появилась возможность провести небольшой "тест": посмотрите на картинки-схемы и ответьте себе на вопрос - всё ли в них понятно? Если что-то в них оставляет неуверенность, то есть, на мой взгляд, некоторая вероятность того, что вы вообще на самом деле не поняли, что такое односвязный список, и может быть, даже не до конца поняли, что такое указатель; возможно, стоит вернуться к началу главы об указателях и пытаться всё осмыслить заново. Реальность с этими схемами такова, как мне кажется: в этих схемах ни единого раза нет ничего такого, чего можно не понять, если вы поняли, что такое односвязный список и что такое указатель;

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

4) Ни в коем случае не пугайтесь того, что задач к самостоятельному решению предлагается две: если вы самостоятельно догадались, как решить первую, решение второй придёт к вам всенепременно в пару-тройку минут;

Re: Брр, указатели

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

5.1) Пустой список - это не запись из пустого поля data и поля next, указывающего на nil. Пустой список - просто указатель на nil, решительно постарайтесь понять, почему это так;

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

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

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

5.5) Dispose уничтожает не адрес, и не адрес и объект, находящийся по этому адресу, а только объект, находящийся по адресу. Четкое осознание этого даст вам понять, что в ходе добавления нового элемента в список вообще уничтожать ничего не нужно.

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

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

Re: Fpc-компилятор в FreeBSD

На вопрос "что это" ответ довольно простой: это у команды, поддеживающей сейчас Free Pascal, кривые руки, вдобавок растущие не будем говорить откуда.

Насчёт "ничего страшного" — ну, я бы не рекомендовал полагаться на Free Pascal в качестве рабочего инструмента, но с ролью учебного пособия он пока ещё как-то справляется.

Re: Планируется ли документация на русском?

Принципиально палец о палец не ударю в этом направлении.

Re: Segmentation fault | Thalassa CMS

Нет, так, конечно, не надо — вылетать по сегфолту всё же моветон. Так что да, сообщайте, буду фиксить.

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

Re: Поисковая машина здорового человека

Поисковиками лучше вообще не пользоваться, но если совсем без этого никак (а когда поисковики со своим brute force approach вытеснили все службы каталогов, оно реально бывает никак), то лично я использую duckduckgo.

Re: readonly прошивки

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

Re: KOI8 в консоли

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

Re: Параллельные вычисления

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

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

Re: Параллельные вычисления

С OpenMP стоит помнить, что изначально его придумывали чтобы взять уже написанный (иногда лет 20-30 назад, даром, что первая версия была для Фортрана) код и распараллелить те места, которые очевидным образом параллелятся. Вроде циклов с независимыми итерациями. Более того, это всё предназначалось не для профессиональных программистов, а для, в лучшем случае, прикладных математиков, в худшем - для исследователей из других областей. Проще говоря - это DSL, который если и применять, то именно для такой специфической ситуации.

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

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

А, да - ваше впечатление про то, как компилятор обрабатывает директивы OpenMP совершенно правильное.

Re: Литература

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

Re: Битая ссылка

Спасибо, всё поправлено.

> Интересно, сколько она там пробыла незамеченой :)

Почти десять лет. Страница не редактировалась с тех пор, как была создана.

Re: Lazarus, окошки и ООП во FreePascal

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

Lazarus — это интегрированная среда, её использовать не надо. Библиотеки, рисующие окошки, доступны вне зависимости от того, делаете вы это в Lazarus'е или в нормальном редакторе.

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

Re: Lazarus, окошки и ООП во FreePascal

>гуй, да ещё и строго "интуитивно понятный".

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

Re: Lazarus, окошки и ООП во FreePascal

> возгордиться тем, что моими программами пользуется масса людей, хочется пораньше.

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

Re: SimpleX мессенджер

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

Вон с моего сайта и просьба не возвращаться.

Re: Ксеоны по 500 рублей

> Прочитал главу про системы и сети.

Ты каким местом её читал?

> а зачем экономить количество процессов?

А где там такое сказано? Ну-ка, давай, быстренько, страница, номер строки, фрагмент текста.

> Старые шестиядерные процессоры Xeon стоят около 500 рублей, что не так дорого.

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

> Можно ли обойтись без разделяемых данных,

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

> при создании серверной программы?

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

> процессы созданные для клиентов

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

Ах, да: вон с моего сайта, а лучше пойди утопись.

Re: Макро система для Си

Слушайте, какое отношение это всё имеет ко мне и к моему сайту?! С моими идеями здесь нет НИЧЕГО общего, подробно разбирать это всё — извините, не вижу веских причин тратить время. Ну то есть пробовать можете что угодно, только просьба такая — никогда, нигде и ни в каком виде не упоминайте меня вместе с этим проектом, поскольку я, разумеется, тут совершенно ни при чём.

Re: Макро система для Си

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

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

> Lua я выбрал потому что его основная структура данных - метатаблица, очень хорошо подходит для хранения синтаксических деревьев.

В Lua настолько любят таблицы, что даже структуры реализуются через них (struct.field эквивалентно struct["field"]). То есть для обращения к полю придётся считать хеш [1] [2].

> 1) делать парсинг Си вручную, чего мне бы не хотелось ввиду объема времени которе это отнимет. 2) использовать yacc/lex/flex/bison как библиотеки (если такое вообще возможно).

Как вы собираетесь отдавать "новый AST" обратно? gcc (а точнее cc1) требует Си файл, а не AST. Вам нужно писать плагин.

> Еще была мысль написать макропроцессор на Хаскеле, ибо ФП

Как в таком случае вы будете распространять программы, которые используют ваши макросы? Бинарник плагина терпеть не будет никто. Если программа будет требовать наличие ghc в системе, то это проглотят почти все, но не пользователи систем, в которых пакетный менеджер не отслеживает зависимости (CRUX, Slackware). Вам придётся добавлять исходники ghc в код программы. Чтобы собрать ghc на системе без ghc нужно скачивать бинарник [3].

> Вопрос тот же, что и у комментатора оригинальной дискуссии: В правильном направлении ли я мыслю? Что можно исправить в идейном плане?

По-моему гиблая затея. Я скорее выберу другой язык, чем Си с новыми макросами, тем более ранее в комментарии про LLVM вы показали непонимание базовых вещей.

> Без LLVM, каждому компилятору каждого языка пришлось бы писать отдельно код для трансляции своего синтаксического дерева в каждую из архитектур, итого 20 x 20 = 400 трансляций.

> С LLVM каждому компилятору языка нужна лишь одна трансляция в промежуточный псевдоассемблер, и каждой архитектуре нужна лишь одна трансляция из этого промежуточного слоя в нужную архитектуру, итого 20 + 20 = 40 трансляций. Результат - существенное снижение количество кода который надо писать (+- в 10 раз).

LLVM 17 состоит из ~трёх миллионов (очень грубо) строк кода и поддерживает ~20 архитектур. gcc поддерживает ~50 архитектур и ~10 языков. Следуя вашей логике, получаем 10 * 50 / 20 * 3*10^6 = 75*10^6 строк кода.

Дам вам (и ещё пользователю под ником Tester) один совет. Приходите тогда, когда у вас уже будет что-то готовое на руках.

[1] https://www.lua.org/manual/5.4/manual.html#2.1 (абзац с "To represent records, Lua uses the field name as an index.")

[2] https://www.lua.org/source/5.4/ltable.c.html#luaH_getshortstr

[3] https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html

Re: знания

По программированию могу вот только свой трёхтомник и посоветовать, если бы мог посоветовать что ещё — не стал бы трёхтомник писать. А вот по математике не знаю что посоветовать.

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

Re: знания

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

По поводу математики, тут наверное вообще нельзя найти книгу, прочитав которую, сразу всё поймешь. Ей надо постоянно заниматься. А.В. вроде советовал где-то задачник Сканави (могу ошибаться), вот с него наверное и стоит начать. Не знаете как решить задачу, значит снова ищете соответствующую литературу.

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

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

В общем, никто вам в голову знания не положит, ищите их сами, sapere aude, ептыть :)

Re: знания

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

Re: знания

Касательно математики нашел когда-то т.н. Roadmap. Там есть диаграма и изложение принципов ее построения. Понравилось компактность тем, их последовательность и предложенные книжки. Правда, все книжки копирайтные, так что libgen.is. Оригинал на github'e. Поэтому сделал github-free страничку, можете заглянуть в гости :)

https://linuxsoid.neocities.org/notes/math

Андрею Викторовичу

Возможно вам будет интересно прочесть этот очерк по обучению математики: https://linuxsoid.neocities.org/notes/math/readme.md. Автор не я, но его мысли мне понравились, несмотря на его "Deeply interested in Philosophy and Religion."

Re: bashонстр на 26048 строк

Внятного предела нет. По этому поводу ещё Оустерхаут (автор Tcl) офигевал — сделал даже не язык, а библиотеку на Си для встраивания скриптингового механизма в программы, а на ЭТОМ стали писать монструозные программы на десятки тысяч строк. Насколько я понял, самого Оустерхаута больше всего изумило, что полученная херня ещё и работает.

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

Re: дожили называется

Как вариант, люди поняли, что если ничего не менять, Раст сьест ядро, и решили, что надо спасать ситуацию. Мол, хотите модный язык в ядре, будет вам C++.

Re: Таблица в Lisp-списке

> использовать для разметки гипертекста Lisp-списки

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

Впрочем,

> Как можно красиво в Lisp-список затолкать таблицу с объединение ячеек?

Вот уж не вижу проблем

(table
    ("one" "two" "three" "four" "five" "six")
    ("red" (span 3 "green") "blue" "black")
    ("alpha" "beta" (vspan 3 "gamma") "delta" "epsilon" "zeta")
    ("cat" "dog" nil "cow" "horse" "sheep")
    (1 2 nil 4 5 6)
)

Можно и иначе, конкретика определяется решаемой задачей.

> Что можете посоветовать?

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

Смешно, ага

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

Ну хорошо, глянем в examples/

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

Остаётся templ_smoky, ну это тот темплейт, из которого сделан сайт thalassa.croco.net, и там да, комменты предусмотрены. А ещё там есть файл README. Но есть одна сложность: в файле README рассказывается, как обращаться с Талассой, но не рассказывается, как настраивать Апач. Вроде бы это не есть зона ответственности документации на CMS'ку.

Ну так вот, thalassa.cgi — это CGI-программа, и надо, чтобы Апач её в такой роли признавал и запускал. Ну вот вам, например, ссылочка: https://httpd.apache.org/docs/2.4/howto/cgi.html

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

Re: Thalassa CMS

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

Re: Поиск начинающих изучать трёхтомник

М-да. Вы тогда ещё попробуйте как-нибудь выпить за трезвость, чо. Вот прямо встать со стаканом в руке, типа, "ну, за трезвость". И выпить.

Re: Поиск начинающих изучать трёхтомник

Хоть бы сообщили адрес электронной почты или jid, что ли...

Re: Поиск начинающих изучать трёхтомник

А стоит ли вообще связываться с людьми, которые с одной стороны посещают эту гостевую книгу, а с другой используют телеграм?

Извинения не принимаются >_<

Re: Требования к языку программирования с "чистой" компиляцией

Дело в чём, я не могу сказать, "правильно" ли вы меня поняли, поскольку не вполне понимаю, например, что такое «заготовить кашу для макропроцессора».

Что бросается в глаза — это что у вас уже ключевые слова образовались, вот эти вот int и float, и наверняка ещё какие-то появятся; одной из моих идей было, чтобы все имена, введённые самим компилятором, начинались с "хитрого символа", чтобы избавиться от ключевых слов в их обычном смысле. Отдельный вопрос, что это должен быть за символ; пунктуационных символов в ASCII не так много, и все жалко вот так вот выбивать из работы, но в общем я склоняюсь к "решётке" «#», ну то есть, в частности, встроенные типы могут называться #int и #float. Впрочем, совершенно не факт, что они должны так называться, с целыми я бы скорее ожидал всяких #int32, #uint64 и т.п., как быть с float'ами — фиг знает. И ещё такой момент, что, скажем, слово #int64 должно компилятором вводиться только при условии, что на данной аппаратной платформе присутствуют 64-битные операции, а если их нет — то не должно быть и слова. Дальше уже библиотека макросов введёт "пользовательские" имена вроде int, longint, hugeint, и вот этот hugeint будет при наличии #int64 определяться как его синоним, а если его нет — то, например, как запись из двух #uint32 (именно "u", программно реализовывать 64-битные операции проще, если оба компонента беззнаковые, даже если сама операция знаковая).

Дальше, наверное, следует определиться с лексическим анализатором. Типы лексем я вижу следующие:

• пунктуационные знаки — любой из символов ()[]{},;` превращается в лексему из одного символа, вне зависимости от контекста; и да, только эти девять (на самом деле я не уверен насчёт обратного апострофа, но первые восемь точно);
• числовой литерал — нечто начинающееся с цифры, $ и цифры, # и цифры, тут я бы не мудрил и сделал такие правила, как в NASM'е, там допускаются практически все способы записи чисел, имеющиеся в Си и в ассемблерах, отличных от NASM; ну вот разве что 0234 в NASM'е всё-таки вроде бы десятичное число, а не восьмеричное, как в Си;
• символические литералы — строки в апострофах и кавычках, а как их потом трактовать — пусть решается уже на уровне макробиблиотеки;
• идентификатор — цепочка из латинских букв, цифр и знака подчёркивания, начинающаяся либо с буквы, либо с подчёркивания;
• специальный идентификатор — цепочка произвольной длины из символов +-*/|\=:.!?$~^%@<>& (возможно, сюда же таки ещё обратный апостроф, но не факт; мне всё-таки кажется, что его лучше считать пунктуацией); очевидное применение этих "специальных идентификаторов" — символы операций (которые по-английски operator, не путать с операторами, которые statement), но на уровне языка это навязывать не надо, пусть после лексического анализа идентификаторы обоих видов будут равноправны;
• ключевое слово — #, после которой следует цепочка из букв, цифр и подчёркиваний;
• макропеременная — #, после которой сначала что-то хитрое, например @, а потом уже цепочка.

А вот дальше начинается интересное. Что можно точно сказать, что должны быть ключевые слова #macro для введения нового макроса и #operator (как минимум с указанием приоритета) для введения символа инфиксной операции, который в том числе может быть и обычным идентификатором (как в Паскале and, or и прочее). Ещё, по-видимому, транслятор должен сам превращать списки в круглых скобках в некие "кортежи", причём в роли разделителей элементов кортежа должны выступать запятая и точка с запятой, приоритет запятой выше, т.е. (a,b;c,d;e,f) — это то же самое, что и ((a,b);(c,d);(e,f)). Судя по всему, нужно ввести понятие "обобщённого значения" — это либо "данные" (data), т.е. такое выражение, которое уже разобрано и известно, что оно имеет определённый тип, либо "не-данные", те же кортежи, или идентификатор, которому пока что не приписан никакой смысл, или один из "оставшихся" символов пунктуации []{}` (NB: в первой версии текста тут ещё точка была, это я был неправ, точка не должна быть пунктуацией).

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

И ещё один момент: вытанцовывается некоторое пересечение чистого Си и ЭТОГО (если, конечно, соответствующим образом описать макросы, причём сделать это в отдельном файле, и файл подключать в командной строке компилятора). Полностью Си на этом не получится, потому что, например, в Си можно написать «a+=-5», и это будет то же самое, что «a += - 5», а тут между += и - придётся ставить пробел, чтобы они не слились в один "специальный идентификатор", но такие отличия можно явно оговорить, а в целом это даст возможность сам компилятор сделать на этом вот пересечении, то есть чтобы он компилировался и компилятором ASNI C, и самим собой тоже. Это решит проблему курицы и яйца, а заодно и "циклических зависимостей" (ночной кошмар майнтейнеров пакетов в дистрах).

Re: Первый компилятор

Для начала не следует путать представление и способ ввода. Перфоленты — это способ ввода, и ещё не самый страшный, коммутационные и тумблерные панели в плане трудоёмкости были пострашнее.

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

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

Пишем Первый компилятор

Пока мы не имеем ни одного компилятора, как мы напишем первый компилятор?

Сначала нарисуем карандашами и фломастерами будущий компилятор на листах бумаги и обсудим его с коллегами. А потом напишем в блокноте программиста приблизительно вот так: http://www.bitsavers.org/pdf/ibm/704/Correll_704music.pdf#page=4

Первый компилятор

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

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

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

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

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

Повторное обсуждение с предыдущей страницы? http://stolyarov.info/guestbook/archive/7/#cmt539

Re: Добавить в FAQ ссылки про обсуждение языка Си

Честно говоря, не понял, что конкретно — в смысле ссылки на какие конкретно комменты — вы предлагаете добавить в FAQ и как озаглавить новый раздел FAQ.

Re: Почему Tcl -- скриптовуха?

Во-первых, лисп, разумеется, не функциональный и никогда таким не был. Во-вторых (и это важнее) кто это тут сказал, что лиспы имеют право на существование в качестве языков для самостоятельных программ (т.е. не в роли встроенных языков, вроде AutoLisp, и не в роли языков для скриптинга)? Нет, не имеют, как и любые интерпретируемые языки. Только конченное чмо может ради собственной вкусовщины создавать на ровном месте проблемы пользователям и эксплуатационщикам, а любая внешняя зависимость времени исполнения (кроме разве что ядра операционной системы) — это именно такая проблема, и интерпретаторы (особенно имеющие свои "экосистемы") тут никоим образом не исключение. А уж Common Lisp — это вообще как лакмусовая бумажка: все без исключения "программисты" (в очень жирных кавычках), всерьёз полагающие, что CL имеет хоть какое-то право на существование, должны быть лишены доступа к компьютерам. Пожизненно. Они просто опасны для окружающих, это намного хуже, чем обезьяна с гранатой.

Теперь основное: почему Tcl скриптовуха? Ну, например, потому что его именно так позиционировал его автор. Tcl вообще, строго говоря, не язык, а библиотека для программ на Си, предоставляющая возможности скриптинга. И, кстати, функциональным он не является вообще ни в каком виде, там нет ни замыканий, ни функций как объектов первого класса, я вообще не вижу в нём ничего от функциональщины. В Лиспе-то хоть что-то есть на эту тему, в смысле Лисп, конечно, не функциональный, но на нём хотя бы можно писать в функциональной парадигме, на тикле — очевидно, нельзя.

И вон с моего сайта. Немедленно. Ещё я на такое времени не тратил.

Re: Это конечно не трехтомник, но все же

> считать этот ресурс аналогом

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

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

> прошу обратить внимание на книгу

Там же нет самой книги, как на неё "обращать внимание"? Копирасты поганые.

Re: Как искать сайты в интернете без JavaScript?

Что везде помойка — это точно. Может, запилить каталог? :-) Ну, типа, вот каталог, сюда можно только сайты без JS, остальные не принимаются.

Re: Как искать сайты в интернете без JavaScript?

https://wiby.me/

Re: Как искать сайты в интернете без JavaScript?

https://wiby.me/

Из описания: "The Wiby search engine is building a web of pages as it was in the earlier days of the internet. In addition, Wiby helps vintage computers to continue browsing the web, as pages indexed are more suitable for their performance."

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

Re: [REMOVED] как образец Tcl/Tk

Чёрт, ну вот какого ляда такую публику тянет на мой сайт, что они тут забыли?

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