Переиздание книг Столярова по программированию

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

Вы недооцениваете масштабы мировой сишности.

У меня были все номера Радио с 70-х по начала 90-х, даже до сих пор ещё где-то нахожу. Про Спектрум там не писали вообще практически ничего. Если что, на их ftp есть сканы номеров за все эти годы, можно проверить :) А бейсик-программы на спектрум не подходили. Особенно меня пугало страшное слово MID-с-крокозяблой

В библиотеках были журналы типа переведённого не помню откуда то ли Байт, то ли Байтик, но там тоже про спектрум практически ничего не было, хоть и с бейсика иногда в тетрадку что-то переписывал. :)

В общем, с информацией по спектруму в наших краях было плохо.

Про Спектрум там не писали вообще практически ничего.

Радио-86РК же. «Гаражная разработка».

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

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

давай сравним количество проектов на си и на фрипаскале.

Я вижу студентов, которые сами пишут несложные, но практически полезные веб-сервисы на Go, а не на тех языках, которые выбраны дл я их обучения в университете.

И пару лет назад читал подобное сишное нытьё: http://esr.ibiblio.org/?p=7711

а стоит ли оптимизировать то что и так работает ради полутора юзеров которые хотят что бы всё летало на pentium 4 и 8 Gb RAM? во-первых, это значительно повысит стоимость разработки. во-вторых, на это потребуется в несколько раз больше времени. в итоге имеем проект который обойдут конкуренты, а в худшем случае проект вообще станет не рентабельным.

а стоит ли оптимизировать то что и так работает ради полутора юзеров которые хотят что бы всё летало на pentium 4 и 8 Gb RAM?

См. выше пример в статье.

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

pentium 4 и 8 Gb RAM

На P4 не поставить 8 Gb RAM, AFAIK.

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

вот те пример как экономика (по мнению Open_Реймонду_Source) линукс (а точнее азурное облачко)

выел из унутри офтопик.

и при снижении roi происходит деградация кода винды.

http://esr.ibiblio.org/?p=8764

Тред не читал, но книги Столярова одобряю.

не только в A4, но и в A6

Там сейчас A5 (самый популярный формат для книг), никакого А4 нет и никогда не было.

В А6 переделать теоретически можно, да, но оно само собой не произойдёт, точнее – все нетривиальные моменты вёрстки (рисунки, таблицы, сноски, знаки на полях) дружно слетят и придётся их как-то там патчить, ставить условную компиляцию, вроде и несложно, но при этих-то объёмах – …

распечатывать по 2 страницы на одной.

Это как раз сейчас в самый раз – получится ровно тот размер, как в книжке.

куда уж проще:

как куда? вот сюда: https://en.wikipedia.org/wiki/Rule_110 :-)

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

Вы недооцениваете масштабы мировой сишности.

Это точно, кстати. Ко мне тут один крендель (вебщик) приходил якобы на частный урок, на самом деле практически сразу признался, что пришёл просто потрепаться. Он мне с гордостью (!) показывал свои арифметические выражения на жабаскрипте на 3-4 строки. Что так писать вообще-то категорически нельзя, мне его убедить не удалось; на фразу «это же никто не сможет прочитать» он ответил «а мне и не надо, чтобы кто попало это мог прочитать», а в то, что он сам через полгода это не прочитает, он просто не поверил.

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

а стоит ли оптимизировать то что и так работает ради полутора юзеров которые хотят что бы всё летало на pentium 4 и 8 Gb RAM?

Во-первых, таких юзеров отнюдь не полтора, не все люди живут в пределах МКАД и не все могут себе позволить каждые три года выбрасывать полностью работающий комп.

Во-вторых, вот что я точно знаю, так это что сами компы тупо не имеют права быть такими, как сейчас, и то, что в последние примерно 20 лет происходит – это не прогресс, а мракобесие: для тех же задач нужны всё более и более мощные машины, потому что говнокодеры считают возможным «пренебрегать эффективностью». Так что вот лично вы виновны во всей этой бессмысленной гонке вычислительных мощностей. Я бы сказал, сейчас быть таким вот сторонником «неоптимизации» – это хуже, чем в третьем рейхе эсэсовцем.

«Сишность», как вы это назвали, — естественное состояние на этапе вывода типов. Для компилятора процедура — это «функция, возвращающая <ничего>».

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

Ну а дурни, пишущие дурной код, были и будут во все времена.

Я вот тоже когда-то давно писал:

if (x)
    foo(),
    bar(),
    baz();

Потом поумнел.

А сейчас разбираю один модуль на php неизвестного авторства… и вижу, кто-то не поумнел :(

Для компилятора процедура

Ещё раз, и медленно: абсолютно пофигу, что там будет «для компилятора». Важно не то, как код воспринимает компилятор (или процессор, или ещё какое железное или программное чудище), а как его воспринимает человек. Термин такой «парадигма программирования» слышали?

про радио-86рк (у меня был, уже после спектрума)

Кстати, его программ в формате аудиозаписей не сохранилось? У меня сам РК валяется, но кассета размагнитилась давно :(

если честно, то я уже не помню.

Написал ведь:

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

Из чего не следует, что его нужно бездумно применять.

Во-первых, таких юзеров отнюдь не полтора, не все люди живут в пределах МКАД и не все могут себе позволить каждые три года выбрасывать полностью работающий комп.

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

Какой МКАД? 32 гигабайта DDR4 стоят где то тысяч 10 рублей. Подумайте кого могут интересовать юзеры которые не могут себе позволить даже это, какая от них может быть прибыль? Очевидно - минимальная, а затрат на хороших кодеров которые будут всё подряд оптимизировать будет очень много.

Задачи отнюдь не те же самые. Основные жалобы на веб браузеры, а веб разросся очень сильно наслоением друг на друга бесконечных новых стандартов. Требования к веб кодерам так же выросли. Теперь уже не отделаться простенькими cgi скриптиками как 20 лет назад. Версия браузера 20-летней давности с современным вебом будет скорее всего не юзабельна. Что ещё? Из того чем пользуюсь сам постоянно ещё различные IDE. Они так же довольно прожорливы стали, но и возможностей опять же в них значительно больше чем в старом добром vim. Оптимизировать их уж вовсе никакой надобности нет по той простой причине что их пользователи 100% могут себе позволить купить достаточное количество RAM.

Кроме того, вобщем то никто не мешает пользоваться ПО 20-летней давности если вы действительно считаете что оно выполняет те же задачи что и современное.

И почему именно последние 20 лет за которые требования к памяти выросли из мегабайт в гигабайты. Почитайте в wikipedia о компах 80-х и увидите что за предыдущие 20 лет требования выросли соответственно с килобайт в мегабайты. Ждём ещё 20 лет когда вырастут в терабайты.

Никогда не испытывал никакого дискомфорта по этому поводу. Скорее напротив, с точки зрения восприятия сразу показалось неестественным это разделение на процедуры и ф-ции. Впрочем, чего вы спорите. Считайте что слово void перед ф-цией означает «процедура» если вам так нравится. Собственно и всё на этом. Хотя напишите `#define procedure void` если уж так нравится это слово.

Чувствуется, что живой и мыслящий человек с убеждениями, а не безвольный винтик. Уважаю таких

Какой МКАД? 32 гигабайта DDR4 стоят где то тысяч 10 рублей. Подумайте кого могут интересовать юзеры которые не могут себе позволить даже это, какая от них может быть прибыль? Очевидно - минимальная, а затрат на хороших кодеров которые будут всё подряд оптимизировать будет очень много.

Только к ним еще нужно купить комп за 30. В старую машину столько не засунешь.

Вы там во МКАДе может слегка оторвались от России, но тут зарплаты бывают по 20 т.р. у людей.

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

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

Оптимизировать кого — веб?

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

Вы сейчас на легковесном ЛОРе сидите. Думаете, сюда миллионы нефти были потрачены на оптимизацию?

monk, призываю вас. Тут человек не знает, как веб оптимизировать.

Почитайте в wikipedia о компах 80-х и увидите что за предыдущие 20 лет требования выросли соответственно с килобайт в мегабайты.

Типичная ЭВМ начала 1980-х http://www.bitsavers.org/pdf/dec/vax/EG-21731-18_VAX_Product_Sales_Guide_Apr82.pdf Основная память от 1 до 8 Мбайт

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

Ждём ещё 20 лет когда вырастут в терабайты.

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

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

Конечно, писать всё подряд на них не стоит. Но я начинаю рассматривать JS как годный вариант для мелких тулз на смену shell.

Посмотрите вот эту реализацию, если интересует: https://bellard.org/quickjs/

Компактная. Можно запускать в интерпретаторе или компилировать в бинарь с байт-кодом внутри. Имеет прямой доступ к основным API POSIX. Ничего лишнего, кроме собственно JS и POSIX-функций, с собой не тащит.

Для скриптов в самый раз.

Может и в учебном процессе пригодится.

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

Под компьютеры какого года необходимо оптимизировать на ваш взгляд?

Не не знает, а не хочет. Точнее, уверен, что этого делать не надо. Это всё-таки две большие разницы.

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

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

Под компьютеры какого года необходимо оптимизировать на ваш взгляд?

Бог с ним с годом. Достаточно чтобы программа этого года работала на компьютере этого года быстрее, чем программа 10-летней давности на компьютере 10-летней давности. Пока на примере офисов, АСУТП и бухгалтерии наблюдаю обратную динамику. Особенно удивляет АСУТП, где после обновления системы на современную время реакции на изменение показаний датчика увеличилось в 10 раз. Зато интерфейс какой красивый…

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

gcc

К нему претензий нет. Для компилятора всегда важнее выдавать лучший код. А если качество кода неважно, то без оптимизаций он очень шустро работает.

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

Да ладно. Лиспу на полтора десятка лет побольше будет. Да и в ассемблерах CALL/RET на функции/процедуры не делится.

Радио-86РК же. «Гаражная разработка».

Радио-86РК к спектруму почти никакого отношения не имеет. Только то, что машинные коды у процессоров совпадали, да и то частично.

А кто сказал, что имел?

Я сказал только, какая литература была в наличии.

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

Я тогда ишшо интересовался, какие системы команд бывают у «больших» ЭВМ, но литературы никакой не нарыл.

Но нашел по некоторым микроконтроллерам.

gcc хорош.

А если в каком-то специфическом случае нужна именно скорость компиляции, а скорость исполнения не нужна, то можно применить tcc. Намного быстрее шпарит код, чем gcc с -O0.

гугл ещё не появился? весёлые наверное были времена.

гугл ещё не появился?

Смешно.

Во-вторых, вот что я точно знаю, так это что сами компы тупо не имеют права быть такими, как сейчас, и то, что в последние примерно 20 лет происходит – это не прогресс, а мракобесие: для тех же задач нужны всё более и более мощные машины, потому что говнокодеры считают возможным «пренебрегать эффективностью». Так что вот лично вы виновны во всей этой бессмысленной гонке вычислительных мощностей.

Вот вы и правы и не правы одновременно. И Reset тоже.

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

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

Во вторых, вот небольшой перечень более обывательского:

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

Хотя и не только графика. Особенно в случае многопользовательских игр важна мощность процессора и объем памяти.

2) Собственно фильмы. Их просмотр. Конечно, кому-то достаточно и dvd и даже vhs-качества, пожатого divx-кодеком, но все же, например современые 1080p и тем более 4K-фильмы требуют совсем других мощностей. При этом задействованы кодеки, например, h265, которые 20 лет назад выдали бы 1 fps в лучшем случае. Конечно, есть ускорители и сейчас они используются, но опять же прогресс в видеокартах - это и прогресс вообще в компах.

А также хранение фильмов и музыки. 20 лет назад места на тогдашних дисках было сильно меньше под это.

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

3) Редактирование своих фильмов и тех же роликов для видеоблогерства. Не касаясь хорошести или плохости самого явления, но факт, что на 20-летней давности компах этого не вышло бы в сколько-то привычном современному глазу качестве. И вообще, помню свой опыт монтирования видео в 2006-м даже году. С sdr (dvd-качеством). Это было печально. Винчестеры тужились, процессоры тужились, программы часто падали.

4) Ультрасложные методы редактирования графики и видео, например, с целью восстановления фокуса, реалистичного масштабирования, продвинутого исправления шума и много чего другого. Сами математические методы были известны зачастую с 60-х - 70-х годов, но вот мощности компьютеров, достаточные для их применения обычными пользователями, а не на суперкомпьютерах появились недавно. Например, массовое использование деконволюции.

Обратите внимание (да, там виндовая проприетарщина с триалом, но все же) на продукцию Topaz gigapixel https://topazlabs.com/gigapixel-ai/ - то, что их софт вытворяет с фото и видео было немыслимо на обычных ПК 20 лет назад. Формально конечно чистка от шума и прочее и тогда были, но это действительно новое качество.

5) Вообще доступ к обработке больших объемов данных. Например, сейчас можно скачать себе 600-700Гб текстов и сделать им индексацию для полнотекстового морфологического поиска. Программы 20-летней давности (которые это могли уже тогда) на таких объемах затыкаются. И это на современном даже железе. Тогда это могли делать лишь на мощных серверах.

6)Пресловутые нейросетки. Например, «развлечения» в виде вставки образа другого человека в видеоряд. Deepfake - программы. Им даже современных можностей маловато.

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

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

Вот такие несколько примеров.

вообще не понимаю как кому то могла придти эта идиотская идея их разделить

Они делятся везде, где есть разница между инструкцией и функцией.

вроде только в паскале

Ещё в SQL, бейсике, …

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

она теперь везде, где нет разницы между функцией и процедурой

А в чём между ними разница?

Кстати «нейросети» в основной массе используются для деструктивных вещей. Например, для показывания тебе «правильной» рекламы.

Из вышеперечисленного ценность представляет только SQL.