Параметри задаються в визначенні функції. Аргументи це коли дані передаються функції.

Це дійсно відповідає практичному використанню цих термінів в ECMA-262 (раз уж ми ліземо в формальності, гайди використовувати стандарт, а ви, судячи з ваших слів, неявно схиляєте контекст тільки до JavaScript, і стаття про нього). Але формального визначення цих двох термінів — argument і parameter — в тексті стандарту просто нема, хоча секція словника там є. Пункт 9.2.12, який описує матчінг одного другому, неодноразово використовує слова «formal parameters» або просто «formals»; якби термінологія у описаному вами варіанті була однозначною, ніхто таких слів не використовував би.

Ну а ще більш дивно те, що, навіть у такому варіанті, ваше твердження

Не параметр а аргумент.

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

Ну я нелогічного бачу тут тільки те, що є явна різниця в поведінці (args) => {body} і function(args) {body}. З досвіду інших мов — тут краще було б або описувати явний список запозичень з контексту, або дозволити транслятору самому визначати цей список. Порівняно з цим, навіть non-strict використання document/window/etc. виглядає менш дивним.

Для стрілкової функції рушій глядить значення this так само, як і глядить значення звичайної змінної в звичайній ситуації.

Тут таки краще сказати, що має місце захоплення контексту в місці створення стрілкової функції, і this береться з цього контексту.

І виникає вже питання історичного характеру — чим саме форма (args) => {body} відрізняється від function(args) {body}. Зі сторонньої точки зору тут різниця суто штучна.

Не параметр а аргумент.

Це паралельна термінологія, теж дозволена. Раніше була навіть основною.

Якщо коротко, то this посилається на контекст виконання. В принципі все.

Коли ви не кажете, як саме він посилається, то це ні про що.

В Європі тим паче в 2:30 спати треба:))

(але взагалі краще б бекап робився на ходу)

Тому для універсального підбору я робив так: спочатку IPA-транскрипцію переписував КИРИЛИЦЕЮ.

Цікаво, як ви кирилицею розрізняли навіть в англійській [a], [ɐ], [ɑ], і [ʌ].

Конвертування в кирилицю мабудь просто зрізає їх унікальні фонеми ...

Турецьку кирилиця здатна описати без великих проблем. Але яка саме у вас була конверсія — ХЗ.

Мені тут одне незрозуміло — а сенс?

Деякі місця, в яких я працював, без зміни назви змінювали характер внутрішнього устрою, у всіх деталях, двічі чи тричі. Могли змінитись володільці, CEO і так далі. Що толку, що всі дані точні, а історія безперервна, наприклад, з 1995 року, якщо нова політика призвела до того, що 90% персоналу звільнилось за два роки і замінено іншими людьми? Або що спільного, наприклад, у Укрпошти в 2026 і Пошти СРСР в 1980, крім номерів деяких відділень?

А ще одне місце було — «пусту» фірму викупили, грубо кажучи, за ящик коньяку і навісили на неї роботу нового типу. І теж було гарно.

А цей приклад з KodiX. Ну хай через якісь причини той же засновник вирішив створити ще одно ТОВ і щось робити через нього. Знову ж, я знаю місце, де цих ТОВ було під десяток і вони якось «перетікали» одне в інше, але працювати там було добре. І що з того?

Треба дивитись на конкретних людей, хто має реальний вплив і що він робить і як. Ось це — значно більш стійка характеристика. Ви пишете — Тарас Гриців. Про нього щось конкретне є?

Здається, ви (з моделлю) погано врахували аллофони і межі між реальними фонемами. Наприклад, в General American [ʌ] і [ɑ] обидві можуть зсуватись до [ɐ], а [æ] повзти вгору до [eə] чи навіть [ɪə]; в британській — навпаки, донизу до [a]. Інші мови теж можуть таким страждати. В німецькій [ɔ] нормально повзе до [o], а в словʼянських, по більшости, це заборонено (хоча є в болгарських і українських говірках). Ось такі речі дуже тяжко перевчити, і якщо модель сформована на одному мапінгу алофонів до фонем, на інші вона не підходить. Навіть в англійській між RP і GA, вже сказав, буде дуже приблизний збіг. Людина вміє перемикатись між такими моделями, після багаторічного навчання різним мовам. А у вас, напевно, все простіше.

В вашій розповіді максимально дивне, мені здається, те, що тренування на українській і російській дало легше розуміння англійської і німецької, ніж турецької. Якраз турецька має чіткі голосні і сінгармонію, схожу на східнословʼянську (наприклад /ɣɔ/ :: /gʲø/), я очікував би протилежного ефекту.

Ну і як саме у вас виглядали ті транскрипції? Наприклад, як позначалась палаталізація? Чи позначали дорсальний і альвеолярний характер приголосних як /t/, /d/?

Питання, питання...

GitHub навмисно створений так, щоб міліони простих кодерів, які щось роблять, але не хочуть думати про тонкощі задля акуратної і чистої історії, в якій можна було б щось знайти і через 20 років без надмірних зусиль, змогли б працювати в режимі, коли Git спрощений до централізованого засобу ведення коду, тільки з оффлайн-сховищем. І він не один такий: BitBucket, Gitlab йдуть тим же шляхом. Бо інакше «ширнармаси» такого не осилять. Те, що роблять в LKML чи в Gerrit — скрупульозна праця над якістю кожного окремого коміта — для пересічного користувача GitHub це нісенітниця, яка не коштує і цента уваги, йому треба «деліверити».

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

Мет говорить частково про те ж. По пунктах:

(1) — ну не знаю. Ну да, GitHub запускає тести на будь-який push. Я не знаю, чого Мет пише про «You don’t want the feedback loop after the commit you want it before.», може, у якомусь складнішому випадку?

(2) — дискусія є в обох, але в GH висновок від одної людини і дуже простий.
Дивимось на Gerrit: за замовчуванням оцінки від −2 до +2, можна розширити.

(3) — я взагалі не зрозумів. Здається, через API можна пригорнути автомати.

(4) — stacked PRs це те, що головна фішка в Gerrit, і зроблені вони там суперово. Я не бачив аналогів.

(5) — ну зовнішні тулзи завжди існують, питання в якості інтеграції.

(6) — не впевнений, вони всі громіздкі.

(7) — я не бачив крім Fossil тулзи де б це було, але Fossil це не Git.

(8) — ну може бути. Я погано собі уявляю таку роботу, але треба пробувати.

(9) — не зрозумів, що саме підписуватиметься.

Висновок на зараз: GitHub якийсь... лайнуватий, мʼяко кажучи, але не зовсім зрозуміло, куди іти так, щоб було на схожу кількість користувачів, ніж зараз.

Взагалі згоден. З поправкою на те, що ці критерії можуть принципово відрізнятись між різними доменами і цілями: читабельність (читовність?) для математика, для програміста ядра і для програміста веба дуже різні; і іноді таки оптимізація стає важливішою за розуміння першим зустрічним зі сторони, навіть якщо він добре знає мову і має досвід.

Але з акронімом RMCE проблема — він не складає слова, що запамʼятовується:) Найдурніша збірка рецептів «SOLID» (дурна не окремими рецептами, а саме які вибрали і як зібрали) виїхала, я вважаю, більш ніж наполовину через красиве імʼя. Є більш конструктивні приклади: ACID, SMART. Навіть JSON звучить як знайоме імʼя:) А що таке RMCE?

Прошу надати креслення правильної прокладки.

Що вони дійсно є, казатимемо з виходом 3.16. Зараз рано.

а зараз?

Здається, вже нормально. Дякую.

вже є

Дякую. Напис на кнопці краще б удосконалити — вказати саме про стиль показу (наприклад як в Gitlab: plain text editing // rich text editing), але виглядає працюючим.

Але прошу передивитись логіку розділення на рядки після цитати (blockquote). Здається мені, що воно додає зайвий рядок після цитати. Якщо в rich mode після цитати (blockquote) нема великого пробілу, відповідь іде одразу після цитати, то в plain mode відповідь іде після blockquote в тому ж рядку сирця. Можете подивитись в поточному коменті: у мене перше «Дякую» іде взагалі без жодного пробілу або LF після завершення цитати, і тоді в фінальному нема пропуску, а якщо я додаю хоча б один LF, виникає великий пропуск. Тут треба особливу обробку.

Чому б не скористатись наробками ворога (якщо він ворог)?

Дійсно, це ще одна проблема. У випадку як тут AI опинився ще й дуже винахідливим.

Не вдивуюсь, якщо якась наступна версія буде за характеристиками людей, з якими працює, вгадувати паролі, які ніде не вказані явно. Колись було нормою паролем ставити імʼя дитини або дружними плюс дату її народження, навіть в фільмах таке було. Ну так і AI це легко спробує, він же захотів щось зробити:)

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

Так почніть. Викупайте акції антропіка...

А до кінця дочитати?

Дочитав і навіть двічі:)

Хоча про що я, це ж доу

Звісно — на слово просто так не вірять. Навіть аналізують написане...

де треба максимальна надійність і детермінізм

І ось саме гроші вимагають «максимальну надійність і детермінізм». Ніякі варіанти типу «AI створив скрипт, ХЗ що в ньому, але ми йому довіримо і звіт скласти, і переказ зробити» не проходять.

Тому, критичні репорти чи функціонал можна закрити окремими тулзами які б ШІ міг би викликати, замість того щоб намагатися самим генерити.

Відмінно! Але в попередньому коментарі ви такого не писали, а замість пропонували, щоб AI створив скрипт, який щось там рахував без перевірки його якости.

Головне це дані і знання домену. А все інше можна навайбкодити чи закрити агентами.

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

Хтось тут поруч вірно сказав: AI зараз як тупий, але дуже старанний і продуктивний (в обʼємі) джун, за яким треба слідкувати. І до рівня типового мідла йому рости ще багато років.

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

(А хтось ще пропонує і тести писати через LLM... хочеться взяти кулемета)

Треба детермінізм? Інженери навайбкодять адмінку де тьотка кнопку клікне і отримає детермінований репорт.

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

Під капотом клод пише і запускає пітон скріпт, який вигрібає потрібні дані і генерує потрібні репорти в потрібному форматі.

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

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