try/catch для того чтобы впоймать или обработать ошибки приложения, которые происходят во время выполнения программы, в if вы можете положить свою логику, которую нужно обработать как ошибку

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

На фото: Ахматова сравнивает распечатку SectorLISP (436 байтов вклюяая сборщик мусора) с романом Андерса Хейлсберга «Сто лет компиляции»

https://twitter.com/tshemsedinov/status/1475602298587987975?t=FZpUjnb8cvj_5r1-yvi1Jw

Привет) пишу сюда первый раз. кто может помочь с файл стримами?
Использую fastify-multipart и при чтении файла прокидываю в req.body FileStream
но при чтении уже в контроллере этот стрим возвращает только первый чанк и виснет

вот пример кода

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

Сложна. Нипанятна

Доброго вечера!
Что скажете о https://github.com/supabase/supabase ?

следим как за альтернативой firebase, выглядит хорошо, особенно реактивные подписки на изменения в PG через WAL.

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

Chapter 7
Proving programs correct
As programmers know through bitter personal experience, it can be very difficult
to write a program that is correct, i.e. performs its intended function. Most large
programs have bugs. The consequences of these bugs can vary widely. Some
bugs are harmless, some merely irritating. Some are deadly. For example the
programs inside heart pacemakers, aircraft autopilots, car engine management
systems and antilock braking systems, radiation therapy machines and nuclear
reactor controllers are safety critical. An error in one of them can lead directly to
loss of life, possibly on a large scale. As computers become ever more pervasive
in society, the number of ways in which program bugs can kill people increases.1
How can we make sure a program is correct? One very useful method is simply
to test it in a variety of situations. One tries the program out on inputs designed
to exercise many different parts of it and reveal possible bugs. But usually there
are too many possible situations to try them all exhaustively, so there may still
be bugs lying undetected. As repeatedly emphasized by various writers, notably
Dijkstra, program testing can be very useful for demonstrating the presence of
bugs, but it is only in a few unusual cases where it can demonstrate their absence.
Instead of testing a program, one can try to verify it mathematically. A
program in a sufficiently precisely defined programming language has a definite
mathematical meaning. Similarly, the requirements on a program can be ex￾pressed using mathematics and logic as a precise specification. One can then try
to perform a mathematical proof that the program meets its specification.
One can contrast testing and verification of programs by considering the fol￾lowing simple mathematical assertion:
Σ
N
n=0n =
N(N + 1)
2
It is claimed that this holds for any N. We can certainly test it for any
number of particular values of N. This may lead to our intuitive confidence
in the formula, such that we can hardly believe it could ever fail.

все круто но в программировании так не работает, в том числе и по причине того что в отличие от формул программирование не линейно, часто событийно и модульно

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

На минуточку, это цитата из "Introduction to functional programming" (John Harrison)
Так что это всё ещё программинг

Я сейчас не вспомню точно источника, но я читал о том что в давности предпринимались попытки создать язык полностью на математической основе с ее же доказательностью (было это во времена prolog и т.п.), и попытки увенчались провалом, да и вряд ли бы программирование было бы сейчас таким как оно есть будь это не иначе. Причина по которой я исследовал старые языки, парадигмы и практики были в том что я хотел убедится в том что какие-то мои идеи новаторские - оказалось к счатью что нет, почему к счастью, думаю понятно, приятно понимать что ты не один.  А то что функциональное программирование существует, становится вновь популярным, никак не мешает этому факту. По факту      как озвучивал Тимур в своих вводных лекциях, многие программисты занимаются monkey patching или много раз пишут вчераподобный (мой термин) код. Костылить вполне возможно и на функциональном языке, да вообще не важно на каком))

Суть в другом. Никакие тесты не покроют всё множество входных данных. Суть - построить модель и её реализовывать. Реализация модели - доказуема формально. А если бизнес начинает отличаться от модели - это уже другая история. Так что главное - построить модель соответствующую бизнесу, как я и сделал в своей либе
Тут картинок нельзя... но дальше в этой главе обсуждается Actual requirements -> Mathematical specification -> Mathematical model -> Actual system

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

На практике, вот эта модель у нас используется на проде https://github.com/chantelle-lingerie/sales/blob/master/doc/model.md

Выглядит вполне доказуемо, расширяемо и что самое главное приемлимо по порогу входа, поздравляю

ну в теории проперти-бейзд тестированием можно покрыть всё(вероятностно) множество входных данных

Спасибо. Буду благодарен за звезду))