Гірше — намагання натягнути сову на глобус, порівнюючі абсолютно різні речі. Ну і до того ж — порт Safari на вінду був зобумовлений тим що під час випуску першого iPhone в Apple було бачення що замість додатків будуть веб-сторінки, оптимізовані під мобілку. То ж треба було дати розробникам можливість якось ці сторінки дебагати в тому ж браузері що на мобілці. Ідея на той час виявилася занадто передовою, тож довелося змінювати ідею та випускати SDK та AppStore. Решта вже історія

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

розвиваючи та захищаючи мову, не треба її калічити таким чином, бо так скоро дійдемо до ідеє відкатити правопис до 19 сторіччя, бо сучасний наскільки я пам’ятаю вже був радянською владою нав’язаний

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

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

Дякую, Swift постійно намагається вилізти уперед :)

Дякую за пропозицію. Моя мінімальна ціль — викласти основи мови. Потім якщо ще буде можливість — взятися за «тонкощі»
Що до Пайтонівської реалізації тернарного оператора, так, мабуть треба згадати. Зараз додам

що мається на увазі, коли написано, що точки є on the same line?

що вони лежать на одній прямій що також проходить через центр координат

І коли вони are not related?

що між ними немає жодного із зв’яків наведених вище

перша формуліровка дійсно не зовсім коректна в прикладі, але так її запропонував Copilot. зараз подумаю як її сформулювати точніше

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

Тут може я не правий, але «базова теорія» для мене не є «вводним курсом», це скоріше щось накшталт матеріалу для досвідченого програміста, що хоче дізнатися про нову мову, або того хто пройшов шлях початківця і хоче систематезувати знання
Щодо match, то його поява для мене була дуже добрим знаком, бо в Swift, що є моєю основною мовою зараз, без нього нікуди

Ну, в цілому asyncio є в планах (коли мова дійде до асинхроності), але до цього ще кілька великих розділів. А ставити розділ про асинхроність раніше, скажімо, функцій — не дуже логічно

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

дякую і за ваші коментарі, але не відчуваю себе достатнім авторитетом щоб оскаржувати термін, який є хочаб більш-меньш загальним

Дякую за зауваження, але я точно не хочу додавати зайві сутності. uk.wikipedia.org/wiki/Обробка_винятків

ну del та pop — роблять різні речі. конструктор list() зазвичай використовується тільки для перетворення, використовувати його замість літералу — дивна ідея
звісно, є певне дублювання, і легасі нікуди не діти, але в цілому команда Python намагається тримати це під контролем

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

«а для чого тоді Wnidows, якщо не використовувати WinAmp?»
обчислення — часте використання Python, але це ніяк не робить NumPy та інше — частиною власне мови
а взагалі, люди на пайтоні пишуть бекенд, скрипти автоматизації, десктоп, тощо

я перепрошую, але стороні бібліотеки, навіть такі популярні як NumPy/Pandas/etc. не відносяться до безпосередньо Python як мови, про що ми говоримо. Це як обговорювати дизайн Віндовс, спираючись на WinAmp

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

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

Ну, тут залежить від досвіду. Якщо не розуміти як працюють higher order functions, може бути складно з декораторами (три рівні вкладеності і усе таке). Але якщо це розуміти, проблем не буде
Мені знадобилися певні зусилля щоб зрозуміти логіку дескрипторів або метапрограмування. Хоча це не те щоб особливо важко. Цікавіше що за багато років це не знадобилося яж ніяк
Ті самі дженерики та усілякі констрейнти у Свіфті потребують більше ментальних зусиль, але використовются набагато частіше

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