так тим більше))

скоріш аналогія на «make all warnings into errors» при компиляції (-Wall -Werror)

нє нє, мова саме про те, щоб взнати про «граблі» в «коробочці» не розкриваючи коробочку.

взнати про те, що «щось там» треба було засетапити перед викликом АПІшки треба не постфактум після місяців юзу, а при перегляді сигнатури в доксіджені над нею))

ну але, звісно, якби горе автори сподобилися б зробити рантайм асерт на «байду вже було засетаплено», то не було б й граблів так довго, бо їх знайшли б при першому виклику))

Тут треба більш сильний варіант: якщо математично доведено. Але ти спробуй доведи!

так от вже «Rust borrow checker» дещо доводить, отже ми рухаємо «в правильному напрямку»))

скрізь так, виключень де такого не буває напевно ще не існує, з flutter з одним з пакетів буквально недавно щось подібне бачив

Так, але баги «різного порядку»...
Звісно, Rust «не порішає всіх проблем»,
але через деякі можна буде переступити й одразу до «більш есеншал» речей, ніж довго й нудно з дата брейкпоінтами репродюсити хто там рандомо мені коцає байтик в структурці :)

«залиште ваші рожеві мрії за дверима заходячи до ...»

abandon hope, all ye who enter here))

але те що буває забувають при тому — який трейдоф, та чи варто того чи ні — буває варто, буває ні.

benchmarksgame-team.pages.debian.net/...​rksgame/fastest/rust.html

який трейдоф, та чи варто того чи ні — буває варто, буває ні.

часом на трейдоф можна (й варто) просто «забити»))

в тому плані, як вже тут поруч й відмічати, M$ вчинили правильно, коли просто забили на деякі «UB оптимізації» для «обдарованих корнер кейсів тестів з 2% перформанс буст», щоб лишити юзерам більш сподіваний юзерекспірієнс))

спробувати?) тобто не знаю, то був просто як цікавий факт, пліз не сприймайте як пропозицію не читати доки

ну мені просто влом перебирати варіанти...
я хочу готовий юз й знати готові граблі одразу...

а не взнати після експериментів, що, виявляється, АПІшка не threadsafe й треба було щось там залокати (звісно, в конкретному прикладі нічого локати не треба, але в загальному буває люди місяцями юзають апішку неправильно, «а потім виявилося» що треба було такіто прекондішени й воно «працювало» чисто випадково))

Ну блін, на трансформаторній будці ж чогось пишуть «не залазь — в’бє», чи «не вмикати, працюють люди» на рубільніках, замість запропонувати самосу залізти й дослідити самостійно де там висока напруга...

Для мене це простіше, ніж коли ця логіка десь схована в неявних операціях.

вона не схована, все на виду Ctrl+Click (а в ідеальному світі взагалі в реалізацію заглядати не треба, див вище приклад про requests.get... ну чи std::lock_guard теж чудовий приклад)

Тому що інколи треба скопіювати. А от абстракція це забороняє. Але я про інше.

хто сказав? чому забороняє? якщо треба то забиваємо на абстрації, й пишемо великий switch))

Візьмемо практичний приклад: socket. Є високий рівень на кшталт asyncio. А от популярної легкої надбудови я не знаю, використовують чисте сішне API без обгорторк. Ніякого class Socket. А раз це не набуло популярності за 30 років, то значить там є свої граблі, тобто абстракція протікає, користуватися незручно: більше проблем.

і в Пайтоні невже ніхто не пише?

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as client_socket:
    тут працюємо з сокетом

# а тут він вже закрився

а взагалі, нічого не знаю, я бачив й С++ обгорики і довкола сокетів, і довкола хендлів... а зараз якесь посилання на «мальйон мух»...

хіба не прекрасно, якби на додачу до const я міг би заспецифікувати такі речі, як, наприклад uncopyable, щоб мій сокет потім при правках ніхто кудись «не стирив», не засторив (можна ж стирити в будь якій з допоміжних, куди я його запихаю, зробити копію й десь зберігати) де не треба й не поюзав після звільнення, чи навпаки не звільнив до того як я завершу роботу...
Ну тобто щоб його мобна було тільки «позичити» на час виклику функції, але не засторити копію «десь там»?

ну от ми тільки що й винайшли Rust))

Звісно, тому цей фреймворк і не використовують. Не розумію навіщо на нього взагалі дивитися?

на вашому проекті не використовують, на моєму (на багатьох, і тут і за океаном) — використовують...
та то мало не «стандарт галузі»...

Якби це було безкоштовно, то люди не дурні, давно б почали використовувати.

знову «мільйон мух»...
так вже ж використовують в тій чи в іншій формі, RAII, unique_ptr, всякі with пайтона, using С#, try з ресурсами синтаксис Джави...
та й Rust «вже використовують», он Лінус повним ходом пропихає... а хто буде з ним не згоден, того обкладе матами й вижене з проекту примусить піти

це якщо щось не працює, якщо працює то щось є дуже великі сумніви що її хтось читає)

а як першопочатково взнати «як воно працює»?

я не хочу читати сорси requests.get й розбиратися з тим всім до глибини ОС викликів/особливостей алгоритмів шифрування...

й, чесно, я ніколи не робив Ctrl+Click по requests.get
але ось
requests.readthedocs.io/...​uickstart/#make-a-request

хіба ж це не прекрасно? ))

Здається мені, що ти пишеш про те, про що ніколи не пробував. tangle, weave хоч раз запускав?

звісно що я не запускав «класичних тулів» Кнута, і навіть не вмію ЛаТеХом))

Але ідея логічно обгрунтувати історію «нафіга оце, як ми сюди прийшли», вона чудесна, й доксіджен, окрім власне доків, чудово катить ))

Literate programming це не документація, де скоріше розповідь, як писалася програма. Крок за кроком.

саме так, саме так! я хочу бачити «звідки то взалося» й «нафіга воно мені»... код повинен проситися «не викидай мене, я потрібен для того й того»...

А не оце от все, що робиться щось «нужноє, полєзноє, важноє», тільки ж хз н@хр*на воно тут в цьому проекті? Як воно мапується на рівкваєрменти/дизайн...

На «серйозних проектах» це називається «трейсабіліті», для того буває навіть спеціальний формат коментарів... а ще реки, й айтеми дизайну мають унікальні ІДшки й їх треба в коді вказувати, щоб потім можна було змапувати що звідки взялося, й чого так, а не інакше... а (для контрасту) на г@внопроектах автори навіть не сподоблюються в назві чейнджліста вказати джира айтем, тому навіть з історії GIT незрозуміло що й звідки взялося, чи можна переробити/модифікувати оцю незрозумілу байду, чи краще присобачити костиль збоку (звісно в «ідеальному світі» на «незрозумілу байду» ще й повинен бути юніт тест, та ще й також з посиланнями на ІДшки реків/дизайну)

Документація же містить все що завгодно, окрім цього. Більше того, часто це просто переказ сирцевого коду.

нє, нє... не переказ сирцевого коду, а щоб навівши на виклик функції я отримав короткий хінт, що вона робить... якщо я хочу зробити (умовно) HTTP ріквест до сайту, то мені глибоко байдуже які там TLS, SSL, й всі оті низькорівневі деталі (доти, доки ліба не заматюкається на помилки з сертифікатом)), що в що загнорнуто, й як воно ходить через сокети і тд...
Я хочу побачити живий приклад, ось це те, що я маю на увазі під документацією тобто така «підказка» прочитавши яку я одразу розумію як то юзати (так, це скорше юзер гайд, якщо використовувати іншу термінологію, але їх ніхто не пише, то яке краще місце для такої підказки, як не доксіджен поруч?)...

Але HTML 5 вже розширив свою зону «відповідальності» також на JS

ну але без ЖС він «сам по собі» ніяк виконуватися не зможе))

та ще й продовжує додавати різні нові API. Використання цих API в JS є нічим іним як використанням HTML :D Хоча це й звучить дивакувато.

ну але реалізувати тільки HTML тегами цикли/функції/кондішени/рукурсую не вийде, доки ми не додамо ЖС примочки від того пана...

тобто мова на HTML тагах без ЖС не є «Тюрінг компліт», ну ніяк не натягти сову на глобус...

а от вже ЮHTML + CSS «при певних умовах» вже «Тюрінг компліт» навіть без JS хоча й така «комплітнес», як приклади там, воно й виглядає доволі юзлесс як й всі решта «брейнфаків»))

Це ж комон сенс, без компілятора або інтерпретатора ваш код — лише текстові файли. ;

Звичайно, ну от до сих пір HTML не мав такого «компілятора або інтерпретатора» (всякі примочки типу Vue та їхні «трюки» не рахуємо), тому стандартний HTML бравзером «виконуватися» в плані «Тюрінг комплітнес» ніяк не міг...

Тепер ми встановили, що той пан написав якуто «примочку» (фреймворк) й тепер може виконуватися за спеціально придуманими тим паном тегами. Це прекрасно :)

Але... на практиці це приводить до того, що ти розкручуєш С++ код, щоб зрозуміти що там як відбувається.

На Сшці так само «розкручуєш», бо шукаєш всі юзеджі отого поінтера й намагаєшся зрозуміти коли ж він там видаляється й там правильно чи неправильно?

Бо абстракції текуть. Це причина чому люди навіть зараз обирають Сі а не C++ та Rust.

Не знаю, чи саме це причина, бо срачі довкола Расту були довкола інших речей, а не «текучих абстракцій»... отож ми не вгадаємо, не придумаємо тут мотивацію замість оригінальних учасників того «срачу» (та й хз що там вони насправді в себе в голові думали)...

А взагалі, які ще «абстрації» й куди вони «течуть»?

Якщо я заборонив копіювання своєї структури даних =delete
то куди «втіче» та абстракція?
Якщо я дозволив лише переміщувати (але не копіювати/клонувати) свою структурку, то поки вона «подорожує» я точно знаю що то, звідки я копіюю інстанс вже «почищено», й якщо я запхав мою структурку в чергу, то вже на «цьому» боці нічого не треба «очищати» й овнером стане той, хто витягне структурку на «тому» боці...

Якщо ж мова про відомий «The Law of Leaky Abstractions» від Джоеля, то так само «за Джоелем» течуть й Сшні абстракції, особливо якщо згідно з
www.state-machine.com/...​-oop-works-under-the-hood
та
www.state-machine.com/...​oc/AN_Simple_OOP_in_C.pdf
жахливий ООП гавновреймворк на Сшці, хоча спочатку все ніби класно, але потім каст на касті кастом поганяє...

люди навіть зараз обирають Сі а не C++ та Rust. І оскільки вони створюють досить стабільні складні системи, то не можна вважати їх дебілами.

А хто казав до вони «дебіли» (якщо не рахувати змісту гнівних постів самого «токсичного» Лінуса, коли він періодично обкладає когось «дуже нехорошими словами» за занадто пізній коміт)?

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

Легко таких набрати в тім? Ніразу не легко!
А багато задоволення всією тімою шукати «багу Гейзенберга» бо хтось проявив неуважність?
Задоволення від такого отримують хіба що клінічні мазохісти... а саме головне такі пошуки (часом по пів року, відкладаючи реліз) баги, якої можна було уникнути засобами мови, вони ніразу не додають value до кінцевого продукту...

... до речі, й сам Linux Kernel, навіть написаний на Ciшечці це ж також «абстракція», нє? То, отже «The Law of Leaky Abstractions» аплікабл й до нього))

текст на мові програмування це і є сама точна специфікація

А отут якраз посперечаюся, бо, без відповідного коментаря зробуити за кодом «ментальне зусилля» й зрозуміти чи то «баблсорт» чи таки щось інше — займає час...

Іншими словами коли девелопер прочитав працю якогось ученого і реалізував в коді (не вказавши лінк на джерело ідей), то той код ніфіга не еквівалентний науковій праці з якої він зроблений з точки зору сприйняття людиною...

Для того, між іншим, Дональд Кнут й придумав свій «Літерейт програмінг», звідти й усі доксіджени, ЖС доки, Сфінкси, ЕмКадокси та решта...

Для всіх готовеньких ліб/вреймворків всі читають готову документацію, замість читати сорси...
Але в той же час чомусь розраховують, що власне написане ними буде «і так понятно»...

Теги дають певну перевагу. Це DOM та купа методів по роботі з ним. Замість того, щоб писати синтаксичний аналізатор, який жере дофігаліард ресурсів, теги можна перебрати рекурсивно та дешево, а половину роботи взагалі зроблять розробники браузерів за тебе, оптимізуючи код браузера та пришвидшуючи стандартні функції.

То це той пан перевинайшов XSLT Lisp, тілки не на «S-Expressions» а на HTML тегах, й з АПІшкою готовенького DOM замість ліспівських car/cdr

Лінк на новий фреймворк «в студію»!

Звичайно, але тоді треба так і написати
-> «новий інтерпретатор/компілятор/фреймворк від Олександра Шпака перетворює HTML конструкції на виконуваний код» (бо, без отого самого «інтерпретатора» на стандартному бравзері, без тих доліпок, що їх задизайнив Олександр Шпак виконати кастомні конструкції придумані Олександром Шпаком не вийде))

нічого не зрозумів але дуже цікаво то все вже злісний оффтоп))

Вона повна різними JS інтерфейсами, як то LocalStorage, або різного типу воркерів.

ну але ж сам HTML не може до неї звернутися, ага...

<foreach from="arr" item="a">

без прикрученої збоку додаткової ЖС машинерії — не робе

ші-пілятор за тим всім слідкує

наразі не слідкує))
бо якраз

відклавши в бік питання якості/результатів на сьогоднішньому рівні

...
хоча ідея Spec-driven development доволі хороша, може хоч таким чином заставимо людей писати коментарі/документацію :D

А що, є бодай один CPU, який розуміє класи та іншу оту всю «магію» ООП?

та вони навіть процедур процедурного не розуміють, коли оте от

BX LR

Що таке метод? Яка інструкція за нього відповідальна?

і не треба ніяких інструкція для метода))

Можна. Тільки відрізнити ООП від не-ООП буде доволі важко. Візміть будь-яку програму та спробуйте по її бінарнику дізнатися, в якому стилі там її вкодували.

Ну можна ж робити «ООП» на асемблері, отож, якщо дизасебмлювати, то це з буде ООП тільки зі зміщеннями замість назв полів чи віртуальних функцій))

А якщо мова за умовний .NET то воно взагалі декомпілюється офігенно))

Ось така конструкція використовується в моєму фреймворку.

нє нє, «ета другоє»,
треба щоб «штатний», «рідний» HTML виконувався самим штатним бравзером, без JS/CSS, плагінів та допилів...

А якщо фреймворк інтерпретує HTML, то це вже «нето» ))

(десь тут поруч XSLT та решта штук...)

а ресторити цю вінду, коли теща клацне на кнопку «скачати сильна молитва за любого зятя.ехе» — хто буде? =)

так отожбо й воно ))

В моїх батьків Лінукс стоїть вже 15 років (ну стояв донедавна, я апдейтнув, бо софтини типу рімоут дестопів відмовилиись працювати, і нічого =)

моє шанування, скидаю капелюха