%очевидный вброс%

>>21357
На самом деле, у нас просто появились диспутеры.
В частности >>21348 и >>21349 куны из нити для помощи.
Сама идея этой нити, кстати, тоже назревала давно.

>>21358
Что-то спорщики сразу остыли.

Что вы тут устроили, а меня не позвали?

>>21364
Ну, я ответ на свой вопрос «A или B» давно получил, на побочный вопрос «почему не C» ответил и позицию свою пояснил, надеюсь, понятно. Продолжать бесполезные споры о том, какой из “Best 100 JS template engine 2018” лучше, когда они все делают одинаковые вещи за одинаковое время, с боевыми Семёнами не вижу смысла.

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

>>21367
>динаковые вещи
Да.
>за одинаковое время
Нет.
Если тебе три строчки отрендерить, то пофигу, а допустим на треде из 500 постов уже сильно заметно.

>>21368
Специально замеряла время рендеринга этого >>19666 треда, когда парсер оптимизировала. На P4-M Northwood 1.2 GHz (режим энергосбережения) Opera Presto 12.18 оно составляет жалкие 0.15 s у Handlebars и JsRender. Надо ли говорить, что на более современных Лисе и Хроме рендеринг вообще пролетает со свистом, т.е. минимум в 5 раз быстрее. Инкрементальное обновление вообще находится на уровне погрешности измерения. Ни нада мне тут сказочки про тормоза рассказывать, я их сама кому хочешь могу рассказать. Разница замечается лишь при рендеринге от 100 тыс. элементов и выше.

>>21378
Строго говоря, аппаратных декодеров инструкций в процессорах нет со времён Windows XP, т.е. с 2003-го года. Даже в моём Нортвуде уже нет. Т.е. ваши х86 инструкции на лету преобразуются в последовательности внутренних инструкций процессора и весь экшон, вроде кэширования и предсказания, происходит уже с ними. Производитель процессора в свою очередь не только оставил за собой право менять таблицы трансляции по своему усмотрению, он изначально ввёл возможность менять их в рантайме. Посему ваш x86-ассемблер сейчас — это такая же абстракция, как и байткод в Бидоне или Джаве. Просто зацените юмор, если можете.
>Зависит от понимания понятия "понимать".
>Вот возьмём условие: if cond then trueBranch else falseBranch.
В 70-х было экспериментально доказано, что условные конструкции доступны для понимания шимпанзе, т.е. для их освоения антропоидами нужен просто язык в котором они есть.
Более сложный пример:
Код

Y := 0;

if X > 0 then

   Y := 1;

end if;

работает в разы быстрее, чем алгоритмически аналогичный код

if X > 0 then

   Y := 1;

else

   Y := 0;

end if;

Можете объяснить это или всё сведётся к тому, что это специфика данной среды выполнения и надо просто запомнить?
>Если же тебя интересует низкий уровень - что там во что транслируется, и куда переходы генерируются, то митовский курс как раз заставляет тебя пилить самый обычный современный ARM-процессор.
99% упирающихся лбом в производительность людей, интересует, как работает конкретный процессор или семейство процессоров с которыми им приходится работать, а не сферическая теория в вакууме. А поскольку производители процессоров такой инфой делиться не хотят, лично я предпочитаю аутировать в виртуальной машине и пинать производителя за то, что эта машина на его процессорах медленно работает.
>Сишка живее всех живых.
>Кресты переживают второе рождение.
Кто-то пишет на них не под конкретное железо?
>А у тебя весь мир жабой ограничивается.
У вас. Я про Тьюрингову яму не просто так вспоминала.
>А так же модные нынче штуки уровня input.split(x).map(split(y)).flatten().filter(a).map(b).filter(c).reduce(w).
Это и есть лапша в функциональном стиле. Чем она вам не нравится? Вы же сами советуете припасть к ключу мудрости ФП, только забываете о проблемах ФП, над которыми лучшие умы 20-ть лет бились.
>А потом я сижу за таким вот веб-сайтом и удивляюсь, как сраная страничка может отжирать полгига памяти и тормозить.
А я вот смотрю на страницу с темами у Лисы: туда горе-дизайнер напихал CSS-анимаций, они грузят проц на 100% и вешают лису намертво. А у вас всё Джава виновата.
Ну и вообще, любая оптимизация — это дополнительный код и дополнительная сложность. Люди, которые не знают, куда деть 128 GB RAM, за них платить не хотят. Так какого беса ради кто-то должен бесплатно снижать, допустим, потребление памяти с _n!_ до хотя бы _n^3_ ?

>>21404
> Строго говоря, аппаратных декодеров инструкций в процессорах нет со времён Windows XP, т.е. с 2003-го года. Даже в моём Нортвуде уже нет. Т.е. ваши х86 инструкции на лету преобразуются в последовательности внутренних инструкций процессора
Если бы аппаратного декодера не было, то приходилось бы преобразовывать ассемблерные инструкции в µops микропрограммой. В современных x86-процессорах (Transmeta не считается) такое делается только для сложных инструкций, для которых необходимо много µops, например для CPUID, POPF и IDIV. Ты, по-видимому, под "аппаратным декодером" имел в виду то, как было в Pentium MMX и ниже, но это конец 90-х, а не 2003.
> весь экшон, вроде кэширования и предсказания, происходит уже с ними.
Кэширование происходит с обычными инструкциями (но не в твоих Northwood и других NetBurst) и в некоторых процессорах также с микрооперациями (Intel, начиная с Sandy Bridge).
> он изначально ввёл возможность менять их в рантайме.
Ты имеешь в виду macro-op fusion (который не является полноценным изменением в run-time и по сути статичен) или обновление микрокода?
> 99% упирающихся лбом в производительность людей, интересует, как работает конкретный процессор или семейство процессоров с которыми им приходится работать, а не сферическая теория в вакууме. А поскольку производители процессоров такой инфой делиться не хотят
Для таких людей производители выпускают руководства по оптимизации и понаделали кучу счётчиков микроархитектурных событий.
> лично я предпочитаю аутировать в виртуальной машине и пинать производителя за то, что эта машина на его процессорах медленно работает
Как успехи в пинании производителя процессоров?
> Кто-то пишет на них не под конкретное железо?
Да.

>>21407
«Если бы у бабушки был член, была бы она дедушкой.» Имелся в виду аппаратный декодер, не надо тут лить, что «он у нас в целом аппаратный, но некоторые части — софтовые».
>производители выпускают руководства по оптимизации и понаделали кучу счётчиков микроархитектурных событий
Содержание этих специфичных талмудиков в лучшем случае описывается известной фразой: «Ты туда не хады, ты сюда хады, а то снег в башка пападёт — савсэм мёртвий будэшь!» В худшем... Про NetBurst рассказывать надо? «Она работает странно, но мы вам об этом не скажем. Аутируйте ночами в счётчики микроархитектурных событий и пытайтесь понять, что происходит в черном ящике. А мы пока подготовим новую версию ящика, где заменим половину кишок, чтоб вы не расслаблялись.» Мне как-то уже не интересно подобной фигнёй заниматься, к тому же бесплатно.
>Как успехи в пинании производителя процессоров?
Как-то даже задумываться не приходилось, какой там процессор. Вот об алгоритмах думать приходится часто. Забавным здесь видится ещё то, что по итогу тормозит всё всегда почему-то у железячника.
>Да.
laba10.cpp? Потому что что-то сложнее приходится портировать.

>>21409
> Имелся в виду аппаратный декодер, не надо тут лить, что «он у нас в целом аппаратный, но некоторые части — софтовые».
В современных процессорах обычно есть несколько аппаратных декодеров, которые могут декодировать большинство инструкций (в твоём Нортвуде есть только один аппаратный декодер). В старых x86 (где x < 6) принципиально декодер тоже не был полностью аппаратным, микрокод для декодирования использовался ничуть не меньше. Непонятно, откуда мог взяться твой тезис о существовании аппаратных декодеров ранее и их исчезновении в 2003 году.
> laba10.cpp? Потому что что-то сложнее приходится портировать.
Платформа для отличных от ассемблера языков есть не столько архитектура "железа", сколько интерфейсы используемых библиотек и программ. Проблем с портированием с x86-64 на 32-битный ARM почти нет, если речь идёт не об одновременном переносе под другую ОС.

>>21404
> Можете объяснить это или всё сведётся к тому, что это специфика данной среды выполнения и надо просто запомнить?
Чем откомпилированный и в какой среде выполняющийся первый вариант кода работает в разы быстрее? Очевидно, что оптимизирующий компилятор, как правило, должен преобразовывать оба варианта в одинаковый машинный код, а в случае компиляции без оптимизации более быстрым может оказаться любой из вариантов в зависимости, например, от того, будет ли во время выполнения X положительным или разместит ли компилятор X в регистре или в памяти.

>>21474
>На два уровня вверх — это тоже уже неприятно, и по-хорошему, от такого тоже надо избавляться.
Вообще пофигу, если этот код помещается на один экран, лол.
>Я бы, в описанной ситуации, для начала попробовал бы выделить случаи с break в отдельный метод.
Я не понял, чем твое решение фундаментально отлично от моего.
>Эксепшен, хотя бы, ведет точно вверх и, поднявшись по цепочке, всегда можно найти, где он ловится…
Ну низнаю. Если так рассуждать, всегда можно открыть дебаггер и найти значение глобальной переменной, лол. А в силу сложности отлова этого безобразия, имеет смысл использовать много разных переменных (или битфлагов), чтобы понять, где проблема, как только она возникла.
Эксэпш же, не знаю, его хорошо использовать как идею, чтобы например прибраться, если наша программа конкретно сходила под себя, но обрабатывать ими какие-то ошибки будет выглядеть не сильно лучше, чем retvalue handling, а если мы хотим именно сократить нашу императивную лапшу, я не вижу, каким образом глобальные переменные для этого так уж плохи. Проблема в том, что все функции, использующие это, не будут чистыми, лол, но я какбэ за ответственное и внимательное использование этого. Просто если и правда у нас условные 10 уровней обработки ошибок, то даже если мы планируем что-то, у нас будут такие развесистые условия/вызовы функций, что мы офигеем раз десять, пока будем это писать. Или пока будем писать try/catch или что там.
Я думаю, что я в принципе исхожу из того, что программирование исполнителя - это управление состоянием. И корректное описание возможных состояний через пусть и глобальные переменные - не настолько страшно, чтобы оправдать перевод контроля куда-то вообще черт-те куда (so much for managing the state LOL), что определяется рантаймом и не запрограммировано мной как управителем этого исполнителя.
В общем, мне бы хотелось просто примера (можно линкануть реальный код чегото в опенсосе), где глобальные переменные (ну, или в случае с ооп, какие-то приватные члены класса, которые управляются через методы) будут хуже кидания исключений по
а) краткости кода
б) простоте отладки

>>21404
>>21417

>Можете объяснить это или всё сведётся к тому, что это специфика данной среды выполнения и надо просто запомнить?

Разницу в скомпилированных инструкциях двух вариантов действительно хотелось бы посмотреть. А также то что идёт дальше, поскольку это может повлиять на общую производительность. Но предположу что имелась ввиду компиляция "влоб" без оптимизаций. Тогда первый вариант будет работать быстрее _для ситуаций X<=0_ просто из-за того что операция на запись ячейки памяти отправится в увлекательное путешествие по иерархиям кеша/памяти ДО непосредственной проверки значения, что приведёт к меньшему кол-ву кеш-миссов и меньшим задержкам на ожидание. Всё потому что спекулятивное выполнение не подразумевает изменений внешней памяти(в том числе кешей), иначе неудачный бранч нельзя было бы просто так взять и отменить.

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

mov [y], 0

cmp [x], 0

jle .endif

mov [y], 1

.endif:

для первого варианта, и

cmp [x], 0

jg .elseif

mov [y], 0

jmp .endif

.elseif:

mov [y], 1

.endif:

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

>Вот только чтобы это объяснить нужно как раз знать ассемблер.

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

>Но это всё - подмена предмета спора.

Мимокрокодящий зануда спорит с тем с чем считает интересным кеке

>Наивный компилятор сгенерирует что-то вроде этого

Именно такое я и предполагал. Вооще хотел было проверить по-быстрому какая будет разница, но сгорел от документации к gccшным интринсикам пусть горят в аду её авторы! Подожду пока остыну или не найду другой способ подсунуть нужный ассемблерный код.

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

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

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

Вы своими попытками отлично иллюстрируете то, что я пыталась донести в >>21376 и >>21377. Ладно, дам подсказку: мы на этапе семантического анализа вольны делать с кодом что угодно, пока это не изменяет видимые эффекты, порождаемые кодом.

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

>>21527
>Но выгода-то будет. Хотя бы просто возможность мыслить на низком, высоком и формошлёпском уровне уже позволит тебе решать некоторые проблемы проще и быстрее.
Приведите пример, как знание ассемблера помогает лучше отражать товарооборот http://1c.ru/news/finnews/finnews.jsp?id=439

>>21531
Так в какой среде выполнения разница в разы?

>>21532
В той, фронтэнд которой добавляет служебный код в базовые и/или условные блоки (бывает, что в виде вызова служебных подпрограмм из библиотеки времени выполнения; особенно GNAT это любит). Обычно это фронты строго-типизированных ЯП и JIT-компиляторы. Побочные временные эффекты зависят от специфики ЯП и крутости человека, писавшего семантический анализатор. Иногда это описано в документации на компилятор в разделе, посвящённом производительности, однако чаще всего просто декларируется непредназначенность данного компилятора для приложений реального времени или для них имеется отдельный профиль.

Теперь положите, что счётчики производительности внедряются в начало каждого базового блока, и посчитайте количество блоков в обоих вариантах. Особенно заметно на древних JIT-компиляторах JavaScript.

>>21534
А, гонки на асфальтоукладчиках... Какая именно версия GNAT так делает?
> Теперь положите, что счётчики производительности внедряются в начало каждого базового блока, и посчитайте количество блоков в обоих вариантах.
2 базовых блока в обоих вариантах. Разница в количестве условных блоков.
> Особенно заметно на древних JIT-компиляторах JavaScript.
В скомпилированной версии кода счётчиков уже быть не должно, так ведь? А медлительность интерпретируемых участков не должна заметной (кроме как на стадии запуска), ведь критичные для общей производительности участки кода будут скомпилированы.

>>21536
> 2 базовых блока в обоих вариантах. Разница в количестве условных блоков.
То есть, конечно, 2 и 3, если не забыть о самом операторе сравнения, или "1 с небольшим" и "2 с небольшим", если перед этим кодом длинная линейная последовательность инструкций без переходов и ветвлений.

>>21531

Что за нездоровый шовинизм? Почему это увлечённый человек(использованное мной значения слова гик) не может ничего создавать и увлечён только мимолётно? По себе судите небось? Прямо стошнило и передёрнуло. Куча разработчиков opensource софта с Линусом во главе смотрят на вас с укоризной

>>21536
Все. Так не делают лишь компиляторы примитивных ЯП вроде Фортрана и C. Чем больше вы сваливаете на компилятор, тем больше неконтролируемого программистом кода он порождает.
>2 базовых блока в обоих вариантах. Разница в количестве условных блоков.
Базовый блок — это максимальная ненулевая последовательность инструкций промежуточного представления без ветвлений. Определяется после разворачивания высокоуровневых конструкций языка в промежуточную форму (из-за чего семантический анализ становится итеративным процессом). Все оптимизации производятся над базовыми блоками. Поскольку есть множество способов трансляции исходного кода в промежуточную форму, мы можем только гадать, во что преобразовался код из примера.
Если допустить, что трансляция происходит прямолинейно, то блоков будет 4 и 5 соответственно; если допустить, что имеет место перегрузка операторов, то не всё так однозначно. Есть здесь опасность начать ванговать, что в одиночном if-е одна ветвь потока управления окажется неразорванной бранчами, но мы не знаем этого точно и даже дизассемблер нам не сильно поможет, поскольку компилятор блоки может транслировать по-разному руководствуясь набором эвристик.
Если это JIT, следующий вопрос, которым надо задаться, — а что вообще принято за единицу компиляции? Это может быть метод, блок, цикл, искусственно выделенная область.
>В скомпилированной версии кода счётчиков уже быть не должно, так ведь?
Зависит от выбранной схемы компиляции. Она вполне себе может быть многоступенчатой, с кучей эвристик, что, когда и как компилировать. Здесь каждый дрочит как он хочет, особенно когда разницы с конкурентами не видно, и не особо распространяется о кровавых подробностях, тем более, что они могут быть коммерческой тайной. С другой стороны, программисты решают высокоуровневые задачи и здесь проблемы производительности относятся к компилятору также, как биохимия мозга слесаря относится к постройке дамбы Гувера.

Резюмируя: если только вы не выполняете гос.заказ под странный военный процессор с ограниченными ресурсами, или занимаетесь высокопроизводительными вычислениями (опять же под конкретную архитектуру/процессор и конкретный компилятор), думать о том, что происходит на уровне промежуточного представления в компиляторе вам не только бессмысленно (поскольку от вас ничего не зависит даже авторы GCC затрудняются сказать, когда и какая подпрограмма будет инлайнится), но и вредно: http://samlib.ru/m/marxjashin_s_n/roboty_bozhy.shtml

>>21545
Потому, что создавать — это 10% удовольствия и 90% унылой рутины. Мне сложно представить случайного человека, который согласится тратить большую часть своего времени на унылую херню, которая вместо фана 45% времени приносит головную боль, а оставшиеся 45% не приносит вообще ничего, кроме искривления позвоночника и близорукости. Ну и я ещё не встречала ни одного гика ушедшего дальше чтения научпопа (поскольку универские курсы или слишком скучные, или слишком сложные). Ну и если начнёте интересоваться личностями программистов, писавших код в Линуксе, то заметите, что основная их масса или имеет профильное образование, или учёную степень по CS.

Аватарка имеет поинт на тему, что теперь разница между "mov eax, 0" и "xor eax, eax" скорее всего отсутствует, а если присутствует, то фиг поймешь почему. Также она имеет поинт на тему, что какие-то СЧЕТЧИКИ СОБЫТИЙ не позволят тебе узнать, как работает черный ящик процессор, а позволят узнать, какая операция занимает меньше событий.
Но по-моему, это всего лишь значит, что не стоит учить работу процессоров по современным проприетарным системам. Открытое железо ЕСТЬ - https://en.wikipedia.org/wiki/Open-source_computing_hardware#Fully_open-source_hardware - хотя его немного, и один процессор - это еще не вся машина, на которой можно было бы работать.
Бойкот x86, amd64, ARM, MIPS etc - они не ваши друзья, лол.

>>21547
> Чем больше вы сваливаете на компилятор, тем больше неконтролируемого программистом кода он порождает.
Но не в таких абсурдно больших пропорциях же. В каждый, даже самый маленький базовый блок добавлять — это чересчур, если только это не интерпретируемый язык с JIT-компиляцией или отладочная сборка (либо сборка для профилирования, оценки покрытия кода тестами и т.п.).
> Если допустить, что трансляция происходит прямолинейно, то блоков будет 4 и 5 соответственно
Почему 4 и 5? Будет по 6-7 инструкций промежуточного представления и 2-3 базовых блока. Ты включаешь в количество базовых блоков тот блок, который перед этим фрагментом, и тот, который следует за ним? Тогда да, 4 и 5.
> если только вы не выполняете гос.заказ под странный военный процессор с ограниченными ресурсами
Ты сводишь всю область встраиваемых систем к каким-то военным госзаказам. В сочетании с упоминанием Ada это наводит на мысль, что ты пишешь на этом языке под "странные военные процессоры".
>>21549
> теперь разница между "mov eax, 0" и "xor eax, eax" скорее всего отсутствует, а если присутствует, то фиг поймешь почему
Неудачный пример, потому что разница между этими инструкциями есть: "xor eax, eax" действует на флаги и большинством процессоров распознаётся как инструкция, разрывающая зависимость следующих операций от предыдущего значения EAX. "XOR eax, eax" на современных Intel'ах даже не достигает стадии выполнения, а обрабатывается на стадии переименования и выделения регистров. "MOV eax, 0" не действует на флаги, но не распознаётся, как правило, как нечто отличное от любой другой инструкции вида "MOV eax, число".

>>21549
>Аватарка имеет поинт
Не имеет. Аватарка уводит разговор в сторону от изначальной темы и гнёт законы логики и ведения дискуссии об колено.
>разница между "mov eax, 0" и "xor eax, eax" скорее всего отсутствует, а если присутствует, то фиг поймешь почему
Присутствует. Потому что интол так сделал и написал об этом в своих мануалах. Но их же читать нинужно, потому что всё равно не выучишь работу процессора до конца.
Ну, если их не читать, то действительно "фиг поймешь почему".

>>21353
emacs or vi?

>>22541
PyCharm

>Agile или не Agile?
“The End of Agile”: https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/

>>22541
TECO
А если серьёзно, то ни тот, ни другой не покрывают современные юзкейсы, а конфиги ковырять всё-равно в каком.

>>22548
>то ни тот, ни другой не покрывают современные юзкейсы
И что же они не покрывают?

>>22561
Готовность к работе из коробки и плавную кривую обучения?

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

Это как Paint и AutoCAD сравнивать, такое себе.

>>22566
Всё это в плагинах есть. Мы же не говорим об оригинальном vi? Конечно, стоит заметить, что качество и производительность работы этих плагинов на больших проектах порой оставляют желать лучшего.

>>22568
Если говорить про Vim, то его потолок — это подсветка синтаксиса регулярками, которые спотыкаются об HTML с JS-ом и вызывают кислотного Залго. Остальные его достоинства — это прикольный режим редактирования, который, правда, предполагает, что ты много-много пишешь руками, а не набираешь три буквы и жмакаешь Ctrl-Space и Enter, поскольку контекстно-зависимое автодополнение обычно выбирает нужный вариант.

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

>>22570
>его потолок — это подсветка синтаксиса регулярками
Нет.

>>22573
А что в нём ещё есть такого, чего нет в модерновых редакторах? Причём в последних оно сделано для решения современных задач, а не задач, которые решали инженеры 30-ть лет назад при помощи тогдашнего оборудования, когда то, что сейчас делает IDE из коробки, прилагалось к программе на физическом носителе в виде книжечки в твёрдом переплёте. Я только единственный кейс могу припомнить, где он тащит, — это поиск регулярками в 200-метровом бинарнике.

>>22574
>чего нет в модерновых редакторах
Про это никто не утверждал.

>>22583
Тогда выходит, что сейчас это просто чудной текстовый редактор, один из многих: Editpad, Alkelpad, Notepad++, SublimeText, e.t.c. Конфиги ковырять подойдёт любой из них, для чего-то более серьёзного они не подходят.

>>22585
Мир не делится на конфиги и 20гб жаваподелия.

>>22587
Мир вот уже ~20-ть лет не решает задачки, код которых можно за вечер написать в тетрадке , утром сдать преподу и получить зачёт. Посмотри хотя бы на требования, предъявляемые к industrial grade показометру: ты его ассемблере будешь писать года четыре и по итогу поедешь кукухой от сложности поставленной задачи.

>20гб жаваподелия
Спринг — это вообще такая забавная религия, в основе которой лежит отрицание существования промежутка времени 2011-2019 годов. Они уже «изобрели» фреймворк, позволяющий сделать энтерпрайзный апп-сервер из Jetty своими руками. Теперь они «изобретают» кластер.
Непонятно только, при чем тут они.

>>22588
Что такое показометр и какие требования к нему предъявляются? То что есть в гугле не делает смысла в контексте беседы.

>>22590
Девайс, который некую физическую величину отображает при помощи датчика в виде цифер на семисегментном дисплейчике. Раньше были довольны тем, что он просто показывает эти циферы, сейчас в него надо напихать фарша по уши, чтобы просто быть конкурентноспособным, т.е. то, что ты можешь написать драйвера и измерительную модель — это entry-level, студент с лабой; теперь запили калибратор, предустановленные поправки для разных типов датчиков, возможность добавлять свои поправки, конвертор величин, режимы отображения, цифровые фильтры и трансляцию данных дальше по цепочке таких девайсов, коммуникацию по какому-нибудь протоколу с сервером измерительного комплекса, ивенты в цифре и релейке; плюс нужна самодиагностика и error-handling; плюс настроечки и user-friendly интерфейс, чтобы киповец и технолог могли с ним работать (а ещё желательно, чтобы UI был на их языке, и тут мы выкидываем семисегментный индикатор и драйвера для него, берём экран, способный рисовать графику и пердолимся теперь с ней).

И так везде. Сложность, она не в том, что сейчас используются какие-то хитромудые алгоритмы, понятные 3,5 математикам, а в том, что всего очень много, т.е. не качественная, а количественная. Много функционала, который пользователи считают само собой разумеющимся (не задумывался, кстати, в какую жопу выливается недавний реквест Соуса?), много данных, много типов данных, много систем, много взаимодействий между системами.

>>22592
> чтобы просто быть конкурентноспособным
При всех его неисчислимых достоинствах подобный умный индикатор безнадёжно проигрывает простому преобразователю с RTD на 4-20, к которому прикручен тот самый семисегментный индикатор, по цене и, вероятно, надёжности.

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

В мире всё ещё достаточно места для простых программ.

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

>безнадёжно проигрывает
Любой девайс, работающий с аналогом обязан иметь механизмы калибровки, иначе тебе нужны йоба-датчики, откалиброванные на заводе, но они во-первых, выходят дороже самого йоба-показометра, а во-вторых, зачастую датчики в промышленных установках являются расходниками и их стремятся сделать как можно проще и дешевле. Это во первых.
Во-вторых, производство сейчас имеет информационную систему учёта и контроля, она просто в силу невозможности запихать цеха в серверную является распределённой. Типично для ЖКХ, когда производственные объекты разбросаны по городу и окрестностям. Твой девайс должен уметь интегрироваться в эту систему.

>проектов шкафов управления
Логика == ПЛК, Siemens, например. Никто не проектирует ПЛК для шкафа управления, берут готовые промышленные решения. Проблемы с ПЛК должны решаться за 10-ть минут заменой коробочки. Модернизация логики должна осуществляться через AutoCAD-подобную программу, с которой будет работать штатный релейщик. ПЛК должен уметь интегрироваться в инфраструктуру распределённого измерительного комплекса.
В случае ЖКХ надо в этот шкаф, помимо ПЛК, воткнуть концентратор и GSM-модуль с автономным питанием, которые будут собирать и лить данные на сервер 24/7, поскольку даже шкаф управления насосом в говнокачке сейчас является частью внутренней информационной системы и ведет с сервером высокоинтеллектуальные беседы.

Недавно «Яндекс» сделал сервис к своим картам, позволяющий отслеживать движение автобусов в реальном времени. Такая система в ЖКХ использовалась ещё десять лет назад в целях мониторинга местоположения боевых юнитов, т.е. нихрена не инновация. Для этого надо в каждый автобус запихать йоба-девайс, который умеет в GPS, Глонасс и GSM, но его обслуживание должно быть доступно простому автоэлектрику. Т.е. эта коробка тоже уже не простая, и «на ассемблере за вечер» ей «мозги» не напишешь.

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

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

>>22599
Я всё ещё не вижу, чем умный датчик с кучей настроек и протоколов лучше тупого с одним 4-20 в случае неспециализированного массового применения.
Ремонт в любом случае производится заменой коробочки на заранее настроенную другую, сложность настройки с временем простоя не коррелирует. Калибровка, если под ней понимается определение крайних точек шкалы, с тем же успехом делается в ПЛК. Собственно говоря, сомневаюсь, что сильно распределённые системы делают на одних датчиках, без контроллеров. Скорее это ПЛК объекта интегрируется в систему, а датчики через соответствующий интерфейсный модуль к нему подключаются и в высоких материях общения с сервером вовсе не обязаны разуметь.

> йоба-девайс, который умеет в GPS, Глонасс и GSM
Звучит как обычный мобильник. И мне кажется электрик чтобы его обслуживать не нужен, по крайней мере ни разу не видел в кабине автобуса рядом с водителем электриков. Предполагаю, что в случае поломки эту коробочку заменят в лучшем случае по возвращению машины с маршрута, а специально обученного человека, который будет этим заниматься, достаточно одного на автопарк, что снижает требования к простоте обслуживания.

> Проблемы с ПЛК должны решаться за 10-ть минут заменой коробочки.
В идеальном мире - да. На практике в распределённых информационных системах с зоопарком устройств и не слишком жёсткими требованиями к времени простоя нужной коробочки может и не найтись. А уж из-за одного сгоревшего входа при наличии свободных запасных контроллер никто менять не будет, ибо дорого и даже не факт что быстрее, чем логику поменять.

А логику в ПЛК ты за программу не считаешь? Есть же задачи, которые вполне способен осмыслить и реализовать один человек, но недостаточно простые, чтобы делать их на одних релейных схемах. А IDE, эти самые AutoCAD-подобные, в плане написания кода недалеко ушли от наших продвинутых блокнотов.

>>22602
>Я всё ещё не вижу
Тем, что для неспециализированного применения он ненужен. Сейчас даже автомат на 400 А имеет микропроцессорное управление и является частью информационной системы.

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

>Калибровка
Уравнение y=kx+b в простом случае, кривые, заданные таблично, в сложном.

>Скорее это ПЛК объекта интегрируется в систему
Радиальная архитектура. Количество узлов в под-дереве одного узла зависит от особенностей конкретного объекта. Можешь физически завести всё в один шкаф — узлом будет или ПЛК или частотник. Не можешь — у тебя появится один ПЛК-мама, и кучка ПЛК/УПП/частотников/показометров-дочек, каждая в своём шкафчике. Как и в системах электроснабжения, эта архитектура имеет рекурсивное определение.

>И мне кажется электрик чтобы его обслуживать не нужен,...
Да, она едет под «жопой» у водилы, есть не просит. В гараже вечером автоэлектрик заменяет коробку, старую забирает инженер АСУТП, которому надо постфактум определить, что с ней не так. Т.е. коробка должна иметь интерфейс для связи с ПЭВМ, графическую программу для тех.обслуживания, систему самодиагностики и подробные логи. Также она должна уметь трекать своё перемещение в офлайне, когда выходит из зоны приёма, самостоятельно дозваниваться до сервера, когда снова войдёт в зону приёма и сливать записанный маршрут. Также она должна уметь в security, поскольку её данные секретны. Сложность подобного изделия выходит за рамки «на ассемблере за ночь».

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

>А уж из-за одного сгоревшего входа при наличии свободных запасных контроллер никто менять не будет
До объекта трястись в служебной машине 5 (пять) часов в одну сторону. Дешевле, проще и быстрее заменить коробочку, а с этой разобраться постфактум. Одна из задач, которую в ЖКХ решают подобные системы, — это самодиагностика необслуживаемых объектов и бибиканье нужным людям «мне плохо, навести», т.е. на объект ты можешь зарулить по дороге. Отсюда: 1) тебе надо возить с собой набор коробочек; 2) зоопарка быть не может — если решили ставить Грюндфос, значит везде будет Грюндфос. Другой вариант — это заранее заложить в программу для ПЛК возможность выбора входов, т.е. нужна отдельная менюха для этого, а сам ПЛК должен иметь графический интерфейс на языке потребителя в терминах решаемой бизнес-проблемы, или тебе надо возить с собой ещё и набор инструкций. Тем не менее в объект может просто ебануть молния.

>ибо дорого
>производство (особенно ЖКХ)
Кек. (Они сейчас с роботами играются.) Дорого — это от миллиона. Эти люди не мыслят самоделкиными категориями, у них другие масштабы и задачи. Они и шкафы управления заказывают у специальных организаций, а не собирают сами. Сами они производят только установку и пуско-наладку совместно со специалистами производителя.

>А логику в ПЛК ты за программу не считаешь?
Эту логику делает фирма, занимающаяся производством контроллеров для нужд производства. Она месяцами тестируется в самой фирме, потом подтверждается тестами сторонних организаций в виде сертификатов соответствия, потом подтверждается эксплуатацией у потребителей данной продукции. Сложность подобного изделия выходит за рамки «на ассемблере за ночь». Никто в здравом уме не полезет хачить ПЛК, если только от безысходности в случае дремучего легаси (от самоделкина).

>Есть же задачи, которые вполне способен...
Улыбнул, содомит. Это какие такие задачи решает специализированная ЭВМ (которая конечный автомат по определению), которые специалист не может описать в виде конечного автомата?

>А IDE, эти самые AutoCAD-подобные, в плане написания кода недалеко ушли от наших продвинутых блокнотов.
1) Они — специализированный продукт под конкретные изделия. 2) Это — рекомендованный производителем способ работы с изделием. Как правило производитель снимает с себя ответственность при работе с его изделием какими-то иными способами.

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

>>22607
> уметь в security
"Security" — это нечто отличное от "безопасность"?
> её данные секретны
Лолчто?

Фоська дело говорит, в целом согласен, но все очень идеализированно, в реальном мире все намного грустнее, так что вставлю свои 5 копеек.
Так уж вышло, что я знаю какие коробчки ездят под «жопой» у водилы.
У типичного автобуса на борту установлены:
Датчик уровня топлива. Емкостной. Так как двух одинаковых бак не бывает, его нужно тарировать, т.е. ему нужна система калибровки. Датчик общается по rs485 с коробочкой. В бак наливают N литров топлива, нажимают в коробочке на кнопку в меню, та записывает в память датчика соответствие уровня и объема в таблицу. Повторяют до полного бака.
Датчики температуры. От 2 до 8 штук. Обычные DS18B20 никто не калибрует, но так как все они соединены в общий провод 1-wire, необходимо задавать соответствие, какой датчик стоит где. (Иногда их проводку монтируют "звездой", и поэтому от наводок вы регулярно видите в бегущей строке -100 градусов Цельсия)
Датчики пассажиропотока, по одному на дверь. Стоят сверху. Работают как обычная оптопара на отражение. Интерфейс RS485. Штука понятно неточная, так как протиснуться сбоку легко и мимо них.
Датчик дыма и огня, чтобы водила не думал курить в салоне, ну и на случай пожара. В народе "сиська" за характерную полусферическую форму с цилинром на конце. Дискретный выход.
Твревожная кнопка.
Система видеонаблюдения - аналоговые или IP-камеры, от 4 до 12 штук, видеорегистратор с HDD или SSD на 1-2 Тб, wi-fi роутер, который автоматически сгружает содержимое регистратора на сервер при заходе в парк, где видеозаписи хранятся до востребования, и удаляются по прошествии времени, если происшествий не было. В видерегистратор так же можно вставлять SIM-карту, чтобы он сообщал на сервер о состоянии сигнализаций (от акселлерометра или от датчика
Бесперебойник для питания видеонаблюдения. Умный, способен следить за состоянием батареи, считает количество циклов, имеет софтину для настройки. Помимо этого на борту есть несколько преобразователей и стабилизаторов напряжения, но они тупые и аналоговые.
GPS+GLONASS-навигатор с GPRS, типичный представитель - "Гранит-навигатор 2.07", но есть и другие. К нему подключаются датчики пассажиропотока, температуры, уровня топлива, информацию о местоположении и показания датичков он отсылает на сервер. К нему подключается тангента для связи с диспетчером, на него можно дозвониться с обычного мобильника. Так же по тангенте можно матюгаться через динамики в салоне (хотя я ни разу не слышал, чтоб это делали на маршруте, им проще крикнуть). Так же конкретно эта модель поддерживает фотокамеру, и может по запросу отсылать фотку в диспетчерскую, но не видел, чтобы эта фича использовалась.
Табло светодиодные: переднее, заднее, боковое, табло "СТОП", бегущая строка, дополнительные. Если "Гранит-навигатор" поддерживает управление конкретной моделью табло, то используется он, если нет, то автоинформатор от производителья табло. Автоинформатор имеет флешку, на которую записываются файлы маршрутов и аудиофайлы объявления остановок. Так же к нему подключается тангента для объявления ртом.
Валидаторы и турникет (раньше). Валидатор - сложное устройство, которое поддерживает несколько систем платежей, помимо самого билета, должна регулярно связываться с серверами транспортной кампании, и лишь относительно недавно из них выпилили принтер.
Радиостанция "хитон" - представляет собой обычную китайскую голосовую рацию для дальнобойщиков, к которой прикрутили GPS-модуль, чтобы он по радиоканалу отбивал положение в диспетчерскую так же, как это делает навигатор по мобильной связи. Добавление GPS-модуля в китайскую рацию превращает ее в отечественную разработку и добавляет наценку 500% за такое ноу-хау. По сути является резервной системой, все функции которой и так выполняет навигатор, но стоит на случай потери с какого-то перепуга мобильной связи.
В новых автобусах - LCD-экраны с рекламой. Внутри у них андроид.
В новых автобусах все эти коробочки (видеорегистратор, автоинформатор, навигатор) заменены одним бортовым компьютером на Win 10, со специальной софтиной.
Это все вводная часть.

>>22607
> Также она должна уметь в security, поскольку её данные секретны.
Лол. Самое больше секьюрити - это пароль "123456" перед меню критических настроек, чтобы водила не баловался. В остальном - на IP камерах включен telnet, и к ним легко получить рут, например. Но это при условии, что попадешь в их сеть. Принципиально секьюрити основано на том, что IP серверов в оборудовании прописаны в настройках, и больше они ни с чем не связываются, но например GPS-навигаторы имеют интерфейс настройки через SMS, протокол описан в инструкции и находится в свободном доступе. Все, что нужно, чтобы влезть туда - это знать номер телефона.
Это конечно не касается валидаторов, так как там замешаны деньги и банки, по сути, к ним такие же требования, как к любому кассовому терминалу.
> Также она должна уметь трекать своё перемещение в офлайне, когда выходит из зоны приёма
Нет, не должна. Сигнал от GPS пропадет гораздо скорее, чем мобильная связь, ибо он идет из космоса, и его можно загородить любым высотным домом, а мобильная сеть обеспечивается столбами, понатыканными чуть ли не через каждые 100 метров. В целом, всем плевать, если часть маршрута пропала, автобус за это время не мог улететь на луну. В принципе, на этот случай предусмотрена рация "хитон", но как бы у нее-то сигнал еще хуже, так как она должна добивать напрямую до базовой станции.
> Сложность подобного изделия выходит за рамки «на ассемблере за ночь».
Если брать навигатор, то я бы не назвал устройство таким уж сложным. Это если брать не комбайн, вроде "Гранита 2.07", а просто навигатор. GPS-модуль общается по UART с МК, причем на него не нужно слать никаких запросов и записывать ему какие-то регистры, он просто выплевывает в ASCII текущее положение по стандартному протоколу, достаточно просто написать парсер. В GSM-модуле уже есть сетевой стек, и ему достаточно AT-командами сказать "отошли на такой-то айпишник вот эти координаты", добавь к этому пару дискретных входов и DS18B2, текстовый ЖК экран для отображения координат. Это работа на пару вечеров для самодельщика, естественно такого, кто видит все это не в первый раз.
Потом правда приходит жалоба от потребителя, что у вас коробочка глючная, разработчик делает за вечер фикс, отправляет новую прошивку по принципу "собралось - в продакшен" и "пользователь - лучший тестировщик", с новой прошивкой потом обслуживающей организации приходится бегать ночами с программаторами по 1000 автобусов, в каждом раскрутил-прошил-закрутил. Потом выясняется, что в новой прошивке новые баги, и все повторяется сначала.

> На внедрение самодела заместо готовых решений идут только ушлые управленцы
Дело в том, что любой эффективный и не очень менеджер если есть вариант "нанять 10 инженеров чтобы спроектировать девайс за 1 год" или "нанять 1 самоделкина, чтоб он запилил нам все за неделю" выберут второй вариант, без исключений. Это касается и производителей показометров в том числе, так что не факт, что готовое решение всегда окажется лучше, чем самопал. Были случаи, что на звонок в техподдержку производителя показометров с вопросом отвечали: "извините, проектировщик показометра помер, а мы тут ничерта не понимаем". И иногда лучше и проще иметь при себе исходники и устройство, которое сделано под конкретную задачу и которое можно модифицировать, чем доставать ТП с помагитеунасничегонеработает и получать фигу.
> «я художник, я так вижу»
Я видел провода питания, на которых на одном конце у разъема 1-й контакт красный, другой черный, а на другом точно такой же разъем, но 1-й контакт черный.
> «и так сойдёт»
Как насчет девайса, в котором тысячи точек пайки сделаны вручную, под флюсом ЛТИ-120, намазанным малярной кисточкой по плате и не смытым, где некоторые ножки просто забыли запаять, дроссели намотаны вручную и не виток-к-витку, а как попало, из-за чего те звенят своими ферритовыми чашками как школьный звонок, радиаторы сделаны из алюминиевых уголков, отрезанных ножовкой, а сами платы держатся саморезами на деревянных брусках. Деревянных, Карл!
Все это "готовые решения", выпущенные тиражом в десятки тысяч штук. Так что иногда принцип "хочешь хорошо - сделай это сам" работает.
Собственно, принцип наколеночного производства практикуется везде где можно и где нельзя, даже в критичных сферах, таких как медицина или авиация, даже Боинг нанимает индусов на аутсорсе.
> Эту логику делает фирма, занимающаяся производством контроллеров для нужд производства. Она месяцами тестируется в самой фирме, потом подтверждается тестами сторонних организаций в виде сертификатов соответствия
В этой фирме работают такие же самоделкины, как и везде, а сертификаты выдаются единожды на наименование устройство, из которого можно потом полностью вынуть потроха, и заменить на другие, не меняя при этом существенно TTX, и сертификат продолжит действовать. Что до испытаний, испытания на ЭМС можно провести просто включив прибор в сеть, но не выводя его из спящего режима или не подключая нагрузку, и все хорошо.
Было где-то какое-то расследование, где говорилось о том, как КБ, которому поручили разработку софта для управления шлюзами на реке поручило всю разработку студенту за еду, а профит соответственно оставило себе.
Так или иначе, самоделкины - основа производства, а все сертификаты и испытания иногда не более, чем бумажки.
Ну и о ЖЖ юзера fixik-papus я так понимаю, ты знаешь.

>>22588
>Мир вот уже ~20-ть лет не решает задачки, код которых можно за вечер написать в тетрадке
Я пишу лямбды на AWS.
И вообще, микросервисы рулят.

>>22613
Я про системы, которые внедряли в ЖКХ примерно десять лет назад говорю. Навигаторы ставились на древние ЗИЛ-ы и трактора, так что они бывало реально ехали под сиденьем водителя, ибо больше места им не было. В эти проекты спецом закладывалась возможность тех.обслуживания неквалифицированным персоналом заказчика у которого зарплата была 16 тыр/месяц, и они в гробу видали дополнительную работу. Работает по сей день, кстати, т.е. подход себя оправдывает.

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

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

>>22615
Производство интересует, кого пинать в случае невыполнения обязательств перед заказчиком/клиентами по причине отказа того или иного оборудования. Услуги адвокатов стоят на порядки дороже коробочных решений не говоря уже о том, что незадачливого директора собственник может просто закатать в бетон и нанять более толкового. Как там дела обстоят в дохлых КБ, я не в курсе — не доводилось бывать, извини.

>>22616
>микросервисы
>пишем бойлерплейт для проверок консистентности бизнес-данных
>откатываем распределённые транзакции
Кого будет пинать финансовая организация, например, в случае потери денег из-за того, что клерк получил неконсистентные данные, уже решили? Или, опять таки, для серьёзных применений не подходит?

>>22635
>для проверок консистентности
>пишем бойлерплейт
? Я, кажется, уже говорил, что не надо писать 20гб Жаваподелия. Жсон-валидатор в зубы и вперёд.

>>22637
>“undefined is not valid SNILS id”
Лол. Я и говорю, для задач, где в информационной модели более одной сущности, не подходит. Не-не-не, пишите сами учётные системы на микросервисах, делайте руками работу СУБД при помощи чего хотите, только нормальных людей не трогайте.

З.Ы.: Про распределённые транзакции я так понимаю сказать нечего?

>>22638
>undefined
?
Валидируйте правильно, вам кто запрещает?
>пишите сами учётные системы
Ну я же говорю, мир не делится на конфиги и 40гб 1Сы.
>Про распределённые транзакции я так понимаю сказать нечего?
У меня с ними проблем нет. Ванговать, что у вас за юзкейс, и почему горе-разработчики не могут без 20гб брйлержавакода с ним работать я не собираюсь. Принесите хотя бы ТЗ, тогда с вами можно будет дискутировать.

> Какая IDE удобнее?
GNU + EMACS

> Какой язык лучше?
SCHEME (RACKET, GUILE)

> Agile или не Agile?
RABOTAT`

> ООП нужно, или не нужно?
if language does not support other parading

> Настоящий разработчик вы, или нет?
#t

Востребован ли нынче Blender 3D?

Вброшу свои пять копеек.

>Какая IDE удобнее?

Не так уж важно. Я предпочитаю IDEA.

> Какой язык лучше?

Регулярно задаюсь этим вопросом.

Для прототипирования чего-то с матрицами, лучше Python/NumPy вряд ли что-то есть.

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

Для чего-то сложного хороша Java. Поглядываю в сторону Kotlin. Он также собирается в Native.

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

PHP 7.1 или новее — удивительно, но несмотря на обратную совместимость и проверку типов в рантайме, язык довольно удобен. С надёжным фреймворком вполне может подойти для не особо сложных сайтов. И он довольно быстрый сейчас.

> Какой фреймворк православнее

Возможно, я отстал от жизни, но вроде веб-фреймворки почти все в той или иной степени являются копиями Ruby on Rails. Разве что в Java и C# больше слоёв абстрагирования от БД (JDBC Driver, Connection pool, JNDI datasource, JPA/JPQL).
Вроде есть всякие акторные фреймворки, но я не специалист.

> Agile или не Agile?

Скорее, Agile, но это не точно.

> ООП нужно, или не нужно?

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

1. Минимум undefined behaviour. Унифицированная работа со строками (желательно, единственная кодировка на всех платформах или как-то фиксируемая кодировка исходников через прагмы). Желательно, одинаковая битность типов на всех платформах. В общем, стабильное поведение языка, в т.ч. в работе со строками. Уже на этом этапе Си и Си++ становится почти нереально использовать для больших проектов без встроенного скриптового языка.

2. Сложные типы данных (структуры/записи/объекты). Упрощают код на порядок. Например, вместо 5 списков, оперируем одним списком структур.

3. Сборщик мусора. Со мной многие поспорят, но ИМХО начиная с определенной сложности монолитного проекта, отсутствие сборщика отвлекает внимание разраба с решения проблем пользователя на решение проблем с памятью. Rust не является исключением: он может и гарантирует безопасность, но также требует фокусировки на этом вопросе.
Исключением могут быть языки типа PHP, где обычно программа перезапускается на каждый запрос, а состояние сбрасывается в СУБД или какой-нибудь кэш на файловой системе. Так что польза GC не так очевидна.

4. Функциональные идиомы. Упрощают код на порядок при работе со списками. Код становится компактнее и проще читается. ФП почти невозможно без сборщика мусора.

5. Контроль типов параметров функций и возвращаемых значений. В т.ч. контроль null. Хотя бы в рантайме.

6. Контроль generic-типов. Хотя бы для встроенных коллекций. Хотя бы в рантайме.

7. Возможность осуществить весь контроль типов одномоментно на этапе сборки или на этапе проверки через linter. Это позволяет быть более-менее уверенным в корректности кода без тестирования.

> Настоящий разработчик вы, или нет?

У меня справка есть.

> ООП нужно, или не нужно?

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

Если же говорить только про ООП:

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

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

>>21353

• Быстрая, где ничего не надо настраивать, а все есть. (Goland например)
• Со статичными типами
• Тот, который освещен батюшкой
• Лучше agile, чем не agile
• Где-то нужно, где-то нет
• Да

>>25349
>В т.ч. контроль null. Хотя бы в рантайме.
null — это ссылка, которая не указывает ни на один объект. Если вы работаете со ссылками, как в Java, вы от null не избавитесь никак. Just deal with it. В Аде можно, например, там ссылочные типы стоят особняком.

>>25368
Речь о том, что в некоторых современных языках null либо запрещен полностью на уровне языка и предполагается, где это нужно по смыслу, явно оборачивать тип в Optional/Maybe, либо на уровне языка разрешать nullable-переменные, но явно их отличать, причем так, чтобы более простой синтаксис был у не-nullable (так сделано в Kotlin).

Полностью отсутствует null, вроде, в Расте. Там потенциально нулевая ссылка явно представлена как Option<Box<T>>, а в обычный Box<T> поместить пустоту нельзя.

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

Однако, в случае смешивания, например Kotlin и Java, всё это работает по непонятно (мне) каким правилам. Вроде, если вызывать котлин из джавы, то эта проверка либо становится рантаймовой, либо вообще исчезает, не уверен.

>>25368
И рантаймовая проверка имеет тоже смысл. Не так много, конечно, но имеет. Это fail-fast-поведение.
1. Менбше нагрузка на систему в случае ошибки.
2. Сообщение в логе указывает на место, где ошибка совершена, а не где вызвала последствия.

>>25369
Я хочу лишь указать на то, что null — это одно из значений, которые может принимать переменная ссылочного типа. Так же, как 0 — одно из значений переменной типа Integer. Ну никто же не пытается выпилить 0 из int-а или засунуть его в костыль вроде Option.
>С помощью запретов в системе типов, отсутствие в определённом месте null можно гарантировать на этапе сборки.
Даже деление на ноль на этапе сборки гарантировать нельзя, это всегда ошибка рантайма. Исключением является, наверное, только язык SPARK, в котором каждой функции надо писать математическое доказательство.

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

>>25371
Да, традиционно нулл – часть возможных значений указателей.

> Даже деление на ноль на этапе сборки гарантировать нельзя

Ноль не похож на null.

1. Ноль только деление в арифметике ломает. Обычно в ООП-языках у null нельзя вызвать ни один метод, так что если допустить где-то null, то придётся каждый вызов метода оборачивать в проверку вызываемых объектов на null. Если писать чисто в функциональной парадигме, возможно это не такая большая проблема.
2. Null нельзя получить в результате какой-то базовой операции языка, если его явно не сделать, разве что язык поддерживает арифметику указателей. Исключение: чтение структур данных, подразумевающих значение null (например, JSON). Но тут очевидно, что если в языке так контролируется null, то либо такая десериализация создаст nullable-тип, либо null в этой структуре будет выражаться не нуллом языка, а каким-то другим значением. Null в языке похож на значение енума. Если он где-то есть, значит кто-то явно его создал или язык позволил не проинициализировать переменную, и значение дальше куда-то пробросилось без каких-либо модификаций, ведь...
3. операции никакие, кроме проверки на наличие, над нуллами всё равно невозможны.

> Исключением является, наверное, только язык SPARK, в котором каждой функции надо писать математическое доказательство.

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

>>25372
Разрешение/запрещение null в языке может вообще не влиять на использование памяти, если это механизм времени компиляции: тогда empty может компилироваться в null, это не важно после проверки.

>>25373
>механизм времени компиляции
Каким это образом на этапе компиляции ты можешь узнать, где у тебя в рантайме будут нулы?

>empty может компилироваться в null
И вообще нул - это не тип, а значение типа

>>25374

> Каким это образом на этапе компиляции ты можешь узнать, где у тебя в рантайме будут нулы?
> И вообще нул - это не тип, а значение типа.

Да все нуллы явно в коде прописаны, что тут непонятного? Если язык позволяет неинициализировать переменные/поля, то компилятор видит все неинициализированные переменные/поля на этапе сборки. Даже компиляторы C++ часто имеют возможность подсвечивать это как ворнинги. В джаве оставлять неинициализированными локальные переменные вообще запрещено, а поля класса по-умолчанию считаются проинициализированными как null.

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

Если мы идём по пути котлина, то компилятор видит, когда мы передаём что-то из переменной в переменную. Джава и кресты уже контролируют, что мы не можем передать объект типа A в переменную типа B, который не расширяет тип A.

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

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

>>25377
>мы не можем передать объект типа A в переменную типа B, который не расширяет тип A.

Вернее, B должен быть более общим типом.

Либо A и есть B, либо A расширяет/реализует B.

>>25377
В этом твоем котлине та же проверка на нулл, только в профиль, я так понял. Работая с поинтерами это и так обычно делается.

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

>>25379
Ты меня троллишь, по-моему.
Объясню по аналогии.
Вот у тебя есть

enum Foobar { FOO, BAR }

и ты нигде в проекте не используешь

Foobar.BAR

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

Foobar.BAR

ни в одной переменной?

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

>>25380
Где тут поинтеры, где тут нул?

>>25382
Foobar - это поинтер, неподдерживающий арифметику указателей.
Foobar.BAR - это null.
Если ты его не используешь, он не может появиться в ходе работы программы.

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

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

Затем в коде кто-нибудь пишет, "кладём зелёную фишку в коробку". Компилятор говорит: "ты нормальный вообще?".

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

Я пытаюсь сказать про нулл как значение, которое может появится в ходе выполнения. Например ты объявляешь поинтер на тип. А дальше по коду ты аллоцируешь структуру данных этого типа по этому поинтеру. Но сама аллокация условна, могут случится ошибки i/o например и поинтер останется указывающим в никуда. Далее по коду может быть обращение по нему, и разумеется где-то перед этим разумно сделать проверку на нул. Проверять такое наверное все же не работа компилятора, потому что это условно, это рантайм. Возможно это работа линтера. Но границы функционала могут сливаться.

Я пишу это, держа в уме гошечку.

>>25384

>ты объявляешь поинтер на тип. А дальше по коду ты аллоцируешь структуру данных этого

В моём понимании это эквивалентно такому коду.

Something p = null;

p = new Something();

Т.е. нулл появился не сам. Переменная уже была создана как содержащая нулл. И как следствие, её тип должен был иметь возможность содержать null.

>сама аллокация условна, могут случится ошибки i/o например и поинтер останется указывающим в никуда.

>Я пишу это, держа в уме гошечку.

Я, кстати, не уверен, как это в Go сделано.
Там ведь вроде нет исключений.

Если мы пишем что-то вроде

Something p = new Something();

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

Если же нам явно нужно создать что-то потенциально nullable, а затем превратить в не-nullable, то в котлине есть правила, как эти проверки на null должны в коде выглядеть. Вот документация:

https://kotlinlang.org/docs/null-safety.html#checking-for-null-in-conditions

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

С переменными там можно через Elvis-оператор. Например:

var a: Something? = null



// попытка аллоцировать, завёрнутая в try-catch



val b: Something = a ?: объектЗаглушка

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

Для ошибок там есть интерфейс(тип) error, и обычным делом для функции иметь в добавок к обычному возвращаемому значению так же и ошибку, которая в свою очередь будет nil, если все ок.

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

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

Вторым делом, напомню одну вещь из Жабы: GC грохает лишь те объекты, на которые не указывает ни одна ссылка. Если ссылка с “not null”, то как отправить объект в мусорку? Или коллекции у вас без этого ограничения и возвращают null?

>>25387
Ну это общее правило для сферического gc в вакууме. Поинтер может никуда не ссылаться, но на него ссылаться могут, и тогда в gc он не попадет.

>>25388
Я спрашиваю, как отцепить объект от сети ссылок в языках, в которых есть GC и нет прямого доступа к памяти, если ссылка на него объявлена как “not null”. Обычно единственная оставшаяся ссылка на объект зануляется, и... всё, «мы его потеряли». Аллоцировать в статике константой объект-затычку NotAnObject, который будет имитировать null? Ну и в чём тогда смысл, что проверять на null, что проверять на затычку. Этот подход используется в Аде с 1995-го года в ситуациях, когда отсутствует необходимость вводить ссылочные типы для объектов, но здесь он хотя бы оправдан.

Ну и вам к сведению: поинтер — это адрес в памяти, отображается обычно натуральным числом, и с ним можно делать арифметику; ссылка — это объект внутри языка, обычно содержит адрес и флаги. Не путайте. Поинтер на может быть “constant” или “not null”, в нём просто негде эту информацию размещать.

>>25390
>объект-затычку NotAnObject
В случае с Жабой посмотрите ради интереса, как сделан Collections.emptyList () — ради одной этой затычки создан дополнительный класс.

>>25387
>Если ссылка с “not null”, то как отправить объект в мусорку?
Программа вместе со всеми своими даже синглтонами — не более, чем функция main. И другие потоки — это тоже функции с вложенными блоками кода.
Блоки кода рано или поздно заканчиваются, делая недействительными локальные переменные, которые, если являются объектами со своими полями, утягивают в бездну и их.

>>25390
>Я спрашиваю, как отцепить объект от сети ссылок в языках, в которых есть GC и нет прямого доступа к памяти, если ссылка на него объявлена как “not null”. Обычно единственная оставшаяся ссылка на объект зануляется, и... всё, «мы его потеряли». Аллоцировать в статике константой объект-затычку NotAnObject, который будет имитировать null?
Можно наверное и так, но этим никто не занимается, раз есть GC. Зачем в этом случае программисту думать, что и когда ему обнулить (очистить)? Если алгоритм не допускает утечек, то рано или поздно объекты выйдут за пределы стека выполнения и будут удалены, так и ссылки на другие объекты по мере этого удаления будут постепенно исчезать и они тоже попадут в sweep.

>>25392
>>25394
Так, подождите-ка... То есть, вы делаете микросервисы просто потому, что в вашей парадигме нельзя освободить неиспользуемую память и в итоге при длительной работе она на сервере тупо заканчивается? О, храбрый новый мир!

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

>>25398
>Не понимаю, как ты сделал такой вывод.
Функция main заканчивается вместе с программой, память программы в данном случае освобождается операционной системой, лол. Это подход CGI-bin, там управление памятью не нужно ни в каком виде. Отсюда и вывод.

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

>>25399
GC к функциям не привязывается. У меня такое ощущение, что все в этом треде друг друга не понимают.
>Веруйте, кто ж вам запретит-то.
Хотя зачем понимать, когда можно просто покидаться чванливством.

>>25399
Есть стек вызовов функций или блоков кода, не суть (зависит от языка). Локальные переменные и константы, в том числе not-null, прекращают существовать, когда блоки кода (или функции, зависит от языка), в которых они объявлены, доходят до конца, т.е. когда исчезает этот scope.

Это ответ на вопрос, как GC может подобрать объект, который находится в not-null-переменной. После того, как она исчезнет.

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

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

А вообще, да, GC что-то там мутит с графом взаимосвязей объектов, наверно. В Википедии можно почитать в статье Сборка мусора, как достижимость работает в mark-and-sweep (я не специалист).

Если какие-то объекты были достижимы только как поля объекта, ссылка на который была только в локальной переменной, которая больше не существует, то можно по идее собрать все эти объекты.

>>25402
>GC что-то там мутит с графом взаимосвязей объектов, наверно.
Ты прав. Используются алгоритмы, похожие на Dijkstra's on-the-fly algorithm
https://lamport.azurewebsites.net/pubs/garbage.pdf

>>25402
Если доступ к объекту осуществляется по ссылке, то единственный способ убить объект в языках без прямого доступа к памяти — это присвоить ссылке другое значение. Это вроде бы элементарно. Для этого обычно используется null. Но вы null запретили. Единственный выход у вас — это создать в статике объект-константу специально скостыленного подкласса, который будет заменой null. Но теперь вам надо проверять, не является ли какой-либо объект этой заменой. От чего бежали, к тому и пришли.

У взрослых, т.е. в Аде и Яве not null (@NotNull) — это по сути хинт для компилятора, заставляющий его пихать в нужные места код проверки на null и выбрасывания исключения. Область же применения ограниченных ссылочных типов, вроде

type ObjectAccess is not null access all Object'Class;

крайне ограничена.

Также хочу заметить, что ни один проект не делается с нуля, т.е. в любом проекте достаточно кода, который вы не контролируете. Отсюда любой объект, передаваемый по ссылке, который создан не вами, надо проверять на null.

Лол. Как с вами сложно.

>>25394
> Зачем в этом случае программисту думать, что и когда ему обнулить (очистить)?
Так вот отчего некоторые категории современного софта сжирают столько памяти даже на самый элементарный функционал? Ясно. Понятно. Действительно, зачем думать.

>>25406
А в чем проблема, чванливая няша? Ты пишешь, держа в уме gc, а не беспокоишься в каком месте поставить free. Прогресс не стоит на месте и на дворе не 2005. А память утекает не по этой причине, ты это прекрасно понимаешь, я надеюсь

>>25405
>единственный способ убить объект в языках без прямого доступа к памяти — это присвоить ссылке другое значение

Да не единственный этот способ.

Допустим, есть методы

void doSomething() {

    A a = new A();

    // Что-то делаем.

}



void doSomethingElse(B b) {

    // Что-то делаем c b.

}

Есть некий другой метод. Неважно, в том же классе или нет.

void sdf() {

    doSomething();  // создалась ссылка "a"

    // Ссылка "a" больше не существует.

    // Мы ей не присваивали null, но это и не важно,

    // ведь её больше нет.



    // Ссылка zxc копируется в ссылку "b".

    doSomethingElse(this.zxc);

    // Ссылка "b" исчезла.

}

>>25407
> чванливая няша
Зато не вруша, смешивающая взаимоисключающие параграфы.

>>25409
Ну, во-первых, "зато" вряд ли уместно. Во-вторых, никакого смешивания не подразумевалось.

>>25406
CGI-bin-щикам проще микросервис перезапустить, чем разбираться с памятью. Это у них уже проф.деформация. Ну привык человек всю жизнь гвозди камнем забивать.

>>25407
Я пишу, держа в уме механизмы работы с памятью конкретного языка. GC, malloc, счетчик ссылок. Все эти механизмы имеют четко определённые алгоритмы работы. Ни один из этих механизмов не является аналогом pizdato_lib, т.е. не умеет додумывать за программиста, что делать.

>>25408
В вашем мире проектов уровня laba1 не используются коллекции, многопоточность, сторонние библиотеки; там не надо хранить объекты между запросами, потоками, сессиями; там не порождаются объекты на каждый чих, даже коллекции копий самих себя не создают? Какой чудесный и простой мир!

З.Ы.: Я понимаю, о чём вы говорите, но к реальным проектам это не имеет никакого отношения, увы , если только вы не пишете системы управления для аэро-космической отрасли в стандарте Ravenscar, где ссылки и динамические объекты в бане — тогда делаю реверанс: написать на SPARK-е программу, которая компилируется — это само по себе достижение, можно лечь в гроб и спокойно умереть.

>>25413
Забудь про cgi, это говно мамонта, к микросервисам не относится.

Я полностью согласен про четкий алгоритм работы и что gc не делает pizdato. Gc делает gc, и если не вставлять ему палки в колеса, он прекрасно будет делать свое дело.

>>25414
GC подбирает лишь те объекты, которые он не видит со стэка. Он не может угадать, что вам этот объект больше не нужен. Время жизни объектов, если выйти за рамки студенческих лабораторок и CGI-Bin, может исчисляться годами. Даже на поганом ведрофоне приложения расчитаны на длительную работу в фоне.