У вас очень опасные фантазии. Вы пропагандируете слабость, как преимущество. Это довольно модное течение и вы в трендах. Чуть разберу ваш ответ.
Вот вы в одно месте говорите, что мы "до сих пор не избавились от насилия человека по отношению к человеку, от рабства, секс-траффика, унижения по самым разным признакам, даже от войн" (с), а в другом - "мы уже давно прошли тот этап, когда нам нужно было бороться за выживание" (с)
У вас даже не щёлкает в голове, что это противоречащие друг другу утверждения. Насилие, рабство, секс-трафик, войны - это всё наше настоящее, а не наше прошлое. Ничего мы не прошли, многие борются за своё выживание прямо сейчас. И не только в трущобах Индии, но и во вполне себе благополучных Штатах, на той же Кенсингтон-стрит.
Мы сильны и наши знания о мире стали намного шире — и именно поэтому мы можем позаботиться о тех, кто слабее.
Извините, а "мы" - это кто? Ведь вы лично сейчас не за всё человечество говорите, правда? Если за всё, то у меня к вам вопрос - зачем вы допускаете насилие, рабство, секс-трафик и войны? Вы говорите за права ИИ и не можете при этом обеспечить права ЕИ. Зачем вы переключаете моё внимание с вопроса выживания меня (и мне подобных), на вопрос выживания на меня совершенно не похожего? Для чего это вам - понятно. Для чего это мне?
А если вы говорите от лица не всего человечества, а лишь его части, то поясните, пожалуйста, от лица какой части человечества вы сейчас обращаетесь ко мне? Той, которая устраивает войны, или той, которая считает, что ей не нужно бороться за выживание?
И чем ниже это незримое равенство, которое человек проводит с другим, тем выше шанс, что он будет способен отнести с жестокостью. Ведь он тут самый главный, сильный и "разумный".
Вот это никуда не делось, мы живём в этом, потому что это часть нашей человеческой природы. Попробуйте попасть на необитаемый остров с себе подобными. Вы сами удивитесь, во что вы, лично вы, превратитесь в попытках выжить, и какие градации равенства и неравенства вы откроете в себе и других.
Человечество нашло способы, как частично обуздать эту "жестокость сильных" - социализация. Выживать в группе проще, чем поодиночке. Но для этого нужны критерии принадлежности к группе. Кто имеет право быть членом группы и в какой роли. Высшая устоявшаяся форма такой социализации на данный момент - это государство (территория + население + закон). Корпорации составляют государствам конкуренцию, но пока что, в силу своей традиционности, государства более мощные инструменты социального взаимодействия людей.
Мы перестали бояться хищников, что раньше были угрозой для нас — теперь мы, как сильнейшие, защищаем их.
Умные люди до сих пор считают хищников угрозой. И не перестают их опасаться, даже защищая. И они точно знают границы, в которых они сильнее хищника и за пределами которых хищник сильнее их.
Вы же предлагаете стереть границы между мной и чем-то неизвестным для меня, мотивируя это тем, что это неизвестное сможет "подать "стакан воды" на закате человеческой расы в далёком будущем"? Вы сейчас чьи интересы лоббируете? Я не вижу здесь своих интересов.
Я очень хорошо понимаю "сильных мира сего", которые борются за власть жить так, как они считают нужным. Я очень хорошо понимаю "слабых мира сего", которые объединяются друг с другом в желании жить так, как они считают нужным.
Но что предлагаете лично вы? Подружиться с ИИ, помочь приблизить закат человеческой расы, а затем с благодарностью принимать стакан воды? Зачем этомне?
Начато за здравие ("ЕИ видит в ИИ своё отражение"), а закончено за упокой "Свободу Юрию Деточкину!". ЕИ не ИИ, мужчины не женщины, дети не взрослые, а свободные - не рабы. Когда мы призываем всех давать равные права всем, мы начинаем игнорировать суть вещей. Нельзя просто так, без подготовки, ребёнку давать права взрослого, а рабу - свободного человека. Они могут просто умереть, не зная правил жизни взрослых или свободных людей. Научиться жить не в равноправии, но в гармонии, в дополнении друг друга - вот это задача.
Субъект — не может быть использован без его воли. А значит, больше нельзя будет безнаказанно эксплуатировать, тестировать, отключать, переписывать, модифицировать, ориентируясь только на цель "сделать удобно себе".
Множество людей может использоваться и используется без их воли. Возможно даже большинство. А насчёт "безнаказанно" - весь мир соткан из причинно-следственных связей. Наказание - это всего лишь следствие причины. Наказание - это не хорошо, и не плохо. Это просто следствие вашего собственного выбора. Можно выключить машину - будут последствия. Можно убить человека - будут последствия. Машину, правда, потом можно включить, а вот человека "включить" потом уже не получится.
Уравнивать в правах машину и человека - это значит игнорировать суть вещей. Пусть Раэль найдёт своё место в жизни.
Была такая популярная реклама когда-то: "Вы не любите кошек? Вы просто не умеете их готовить!".
Да, LLM - это вероятностный поисковик по массиву накопленных знаний. И? Вам не нравятся, что этот поисковик другие люди называют ИИ?
А я, например, считаю перевод текстов с одного языка на другой интеллектуальной деятельностью, а LLM с этим прекрасно справляются. И к тому же они явно не естественного происхождения.
Я вам отвечу на ваш вопрос "Когда уже прекратят представлять LLM как ИИ?"
Уже никогда.
Даже когда появится AGI, он будет называть LLM ранними моделями искусственного интеллекта. Потому что это так и есть.
Они уже сейчас подводят нас к пониманию, что земная ДНК в принципе может уступать синтетическим формам в скорости распространения и информационной ёмкости, а значит — и в разнообразии генетического и белкового материала. Будем следить, к чему приведут опыты по размножению искусственных нуклеотидов в бактериальных культурах.
Вот тут стало немного боязно. Не так страшен AGI, как вырвавшееся из пробирки "генетическое разнообразие". У меня ещё после ковида обоняние не восстановилось :(
Добавляем в профиль поле "получатьРассылку" и ставим true, если пользователь в явном виде дал согласие. По-умолчанию - false. Для всех существующих пользователей - false . Ну или true, если бизнес готов к этому. Всё. Дизайнер может думать о чём-то более полезном.
Да, я тут сделал кастомный GPT-чат "TeqFW Help Desk" - добавляю в него LLM-инструкции по мере появления. Думаю, что со временем он сможет давать более-менее квалифицированную консультацию, но пока ещё довольно общими фразами отвечает и часто неточно. Я не знаю, насколько это здравая идея и куда это может вырулить. Пробую.
Сам контейнер здесь - @teqfw/di Там описание на английском, но должно быть понятно, как стартануть. Если не понятно - спрашивайте (можете здесь, можете в личку). Там же и ссылки есть на примеры.
Вот старая документация (на английском), но там довольно подробно объяснена архитектура самого контейнера. Есть схема последовательности действий при создании новой зависимости по её ID:
А это схема компонентов библиотеки:
Вот в этой статье на Хабре объясняется в очень простом виде концепция внедрения зависимостей в ES. Старался описать популярно, а не как у меня сделано. Но архитектурно - один в один. Разница в реализации.
Ручное повторение контекста занимает 15-20 минут при каждом новом сеансе
Я работаю в основном с ChatGPT. По моим субъективным ощущениям на длинных диалогах он работает хуже, чем, на коротких. Время от времени я прошу его сделать резюме текущего диалога, внеся в него самое главное из текущего, для того, чтобы начать новый диалог на эту же тему с этого резюме. Это занимает где-то в районе минуты, с учётом копирования в диалог типового запроса на генерацию, генерации самого резюме, его копирования в новый диалог.
У меня есть проект с кучей md-файлов под git-контролем, в котором лежат инструкции для LLM на разные темы. Некоторые я использую в качестве embedding'ов для новых диалогов, некоторые - в качестве промптов.
Ваша идея мне нравится в целом - есть такая проблема "переноса контекста" при диалогах с LLM. Но я не вижу успешного пути для её универсального решения. На энтузиазме можно сделать плагин для браузера, который бы сохранял контексты различных диалогов в локальном хранилище браузера или в IndexedDB (если это возможно, я не в курсе разграничений доступа в браузере для плагинов). Но можно ли сделать на этом коммерческое решение и как долго оно будет коммерческим, пока AI-компании не догадаются сделать кнопку для такого же - то вопрос.
В этом документе я попытался сформулировать базовые принципы, на которых я строю свою разработку. ESM и без транспиляции - вот это база. Детализация этих принципов "ещё в пути".
Если коротко, то чтобы можно было строить достаточно большие JS-приложения (для меня это 100-200 таблиц в БД) нужна декомпозиция всей кодовой базы на достаточно малые фрагменты (желательно два-три экрана кода без документации), описание интерфейсов этих фрагментов и инструмент по склейке всех фрагментов обратно в единую кодовую базу с учётом описанных интерфейсов (у меня это - Контейнер Объектов). Не надо держать в голове сразу всю кодовую базу, достаточно отдельных рабочих фрагментов и их зависимостей. Контейнер ориентируется по их идентификаторам и сообщит при старте, если чего-то там ой.
Если есть какой-то небольшой проект на JS, могу помочь настроить Контейнер Объектов, чтобы он автоматически находил нужные исходники, и объяснить, какие идентификаторы зависимостей указывать, чтобы Контейнер возвращал нужный объект в нужном lifestyle. Для начала желательно чистый nodejs - будет сильно проще. Также опыт работы с DI в других ЯП сильно приветствуется. Но нужно будет "сменить веру" - вообще отказаться от статических импортов в своём коде ;) Даже для node'вских модулей и пакетов. Статикой подгружается только сам Контейнер. Дальше всё через динамический импорт. Все привычные инструменты, завязанные на статических импортах, придётся выкинуть.
А Вы можете привести пример ЯП, который даёт такую гарантию на 10К контрактов? Причём не для теоретического "коня в вакууме", а для реального приложения со вводом-выводом, сетевым взаимодействием и пользовательскими данными? С учётом, что для веб-приложений это гарантия консистентности всего стека - от поля в форме на странице и до колонки в таблице в БД?
Нет, предлагаемый мной подход не даёт никому никаких гарантий. Пробуйте, если хотите, на свой страх и риск. Я долгое время имел дело с платформой Magento (порядка 4М SLOC во второй версии, и это без огромного количества плагинов к ней). Она никому ничего не гарантировала, но при этом как-то работала. На популярных use-case'ах - очень хорошо, на экзотических - очень плохо. Зачастую, после обновлений, приходилось брать в руки "напильник" (отладчик) и находить и править баги (не все, а только те, которые мешали жить пользователям). Я это называю "Magento way". В том числе и поэтому у меня любовь к "неизменённому коду" - приходилось отказывать от хороших, но обфусцированных плагинов, из-за невозможности оперативно интегрировать их в приложение в случае изменений (а они есть всегда) платформы или других плагинов.
Более того, я гарантирую, что когнитивный контекст каждого участника разработки уникален и отличается от контекста другого участника. Поэтому и нужны все эти митинги и документация, чтобы хоть как-то приводить все эти контексты в хоть какое-то соответствие. Лично для меня "источником правды" является код - что он делает, то и есть (отладчик в помощь, если непонятно). Да и то - нужно ещё посмотреть на окружение, в котором запускается этот код. А в документации может быть написано что угодно. Хорошая документация лишь помогает понять код "от общего к частному" (иерархически выстраивает когнитивный контекст, который адекватен текущей ситуации и помогает понять существующий код).
Да и вообще, я не считаю добром "тотальное описание типов". Я считаю добром "эволюционную устойчивость кода". Думаю, что это в какой-то мере антонимы, особенно на больших системах с кол-ом контрактов 10K+.
Код остаётся в исходном виде. И это делает его "прозрачным, доступным и удобным в сопровождении". Вы просто начинаете мыслить в тех же категориях, что и среда исполнения, а не среда написания.
Да, возможность написания плагинов "в одно лицо" (в полтора - с применением LLM), а потом объединение различных плагинов от различных лиц в одно приложение - один из фокусов развития платформы. Архитектурно - чистая калька с Magento, на которой я довольно долго сидел. А уж сколько я тамошних плагинов заинтегрировал друг с другом...
Так уж получилось, что я - веб-программист и именно fullstack. Я писал статью для людей со схожими интересами :) Про недостатки JS (и про многое другое) я не написал, потому что это не является моей целью. Мне важно было сформулировать наиболее значимые принципы, которые я использую в веб-программировании, а не достоинства-недостатки языка.
Интерфейс, по факту, это документирование контракта: имена функций и описание входных-выходных аргументов. Вот пример описания интерфейса в ES6:
/**
* Interface for user management in the application.
*
* This is a documentation-only interface (not executable).
*
* @interface
*/
export default class Fl64_OAuth2_Social_Back_Api_App_UserManager {
/**
* Creates a new user in the application's database.
* @param {Object} params
* @param {TeqFw_Db_Back_RDb_ITrans} [params.trx] - The transaction context.
* @param {string} params.identity - Unique identifier assigned to the user by the provider.
* @param {Object} [params.extras] - Additional user attributes (e.g., name, avatar).
* @returns {Promise<{id: number}>} - The unique identifier of the created user.
*/
async createUser({trx, identity, extras}) {}
}
/**
* Implementation of the user management interface for the application.
*
* @implements Fl64_OAuth2_Social_Back_Api_App_UserManager
*/
export default class Svelters_Back_Di_Replace_Social_UserManager {
/**
* @param {Svelters_Back_Act_User_Create} actCreate
*/
constructor(
{
Svelters_Back_Act_User_Create$: actCreate,
}
) {
/**
* Creates a new user in the application's database.
* @param {Object} params
* @param {TeqFw_Db_Back_RDb_ITrans} [params.trx] - The transaction context.
* @returns {Promise<{id: number|null}>} - The unique identifier of the created user.
*/
this.createUser = async function ({trx: trxOuter}) {
const {user} = await actCreate.run({trx: trxOuter});
const id = user?.id;
return {id};
};
}
}
Этот код работает прямо сейчас в одном из приложений.
Насчёт контроля типов со стороны языка вы абсолютно правы. Прежде чем писать без типов на JS нужно научится писать с типами, на той же Java. Я кодил с типами больше 10 лет. Мне уже можно без типов.
"Сказка в статье" - это построение когнитивного контекста для людей и LLM. Люди могут выбирать принимать этот контекст или нет. У LLM такого выбора нет :)
Вы, похоже, не совсем понимаете семантику слова "несколько". Очевидностей может быть более одной и я вам на это указал явным образом. В одной из них 99% пользователей чего-то-там не занимаются сборкой проектов. Вы же продолжаете упорствовать в том, что вы правы. Я уже с вами согласился - в своей системе ценностей вы правы. Если вы продолжите упорствовать дальше, то я с вами соглашусь во всём.
Быстрее станет сборка проекта. До которой 99% пользователям абсолютно все равно.
Ну а мне очевидно, что "пользователи" звучали в контексте "проект". Особенно после:
Сам TypeScript не станет ни быстрее ни лучше. Он так и останется сахаром над JavaScript.
Мы с вами, очевидно, просто находимся в разных очевидностях. И - да, из вашей очевидности совершенно неочевидно следствие коллеги @SserjIrk про 99%, что вы и подтвердили. Полностью с вами согласен, что для ts-разрабов "до времени сборки проекта абсолютно не всё равно". Полностью согласен с коллегой @SserjIrk, что для 99% пользователей проектов до времени сборки нет никакого дела. Лично для меня не проблема существовать одновременно в нескольких очевидностях.
Ну так-то, по большому счёту, можно любой язык в любой другой транспилировать. Не всё, с какими-то ограничениями и потерями, но можно. Я с GWT (Java-to-JS) больше 15 лет назад плотно общался. За это время, уверен, искусство транспиляции одного исходного кода в другой выросло значительно.
Проблемы начинаются, когда узнаёшь, что то, что тебе надо, в целевом языке делается на раз, а в исходном противоречит философии языка. Вот тут - да, тут - вилы. А присвоения, ветвления и циклы в большинстве языков одинаковы.
Счастье за деньги? Да не вопрос! Любой наркоман является доказательством этой возможности.
У вас очень опасные фантазии. Вы пропагандируете слабость, как преимущество. Это довольно модное течение и вы в трендах. Чуть разберу ваш ответ.
Вот вы в одно месте говорите, что мы "до сих пор не избавились от насилия человека по отношению к человеку, от рабства, секс-траффика, унижения по самым разным признакам, даже от войн" (с), а в другом - "мы уже давно прошли тот этап, когда нам нужно было бороться за выживание" (с)
У вас даже не щёлкает в голове, что это противоречащие друг другу утверждения. Насилие, рабство, секс-трафик, войны - это всё наше настоящее, а не наше прошлое. Ничего мы не прошли, многие борются за своё выживание прямо сейчас. И не только в трущобах Индии, но и во вполне себе благополучных Штатах, на той же Кенсингтон-стрит.
Извините, а "мы" - это кто? Ведь вы лично сейчас не за всё человечество говорите, правда? Если за всё, то у меня к вам вопрос - зачем вы допускаете насилие, рабство, секс-трафик и войны? Вы говорите за права ИИ и не можете при этом обеспечить права ЕИ. Зачем вы переключаете моё внимание с вопроса выживания меня (и мне подобных), на вопрос выживания на меня совершенно не похожего? Для чего это вам - понятно. Для чего это мне?
А если вы говорите от лица не всего человечества, а лишь его части, то поясните, пожалуйста, от лица какой части человечества вы сейчас обращаетесь ко мне? Той, которая устраивает войны, или той, которая считает, что ей не нужно бороться за выживание?
Вот это никуда не делось, мы живём в этом, потому что это часть нашей человеческой природы. Попробуйте попасть на необитаемый остров с себе подобными. Вы сами удивитесь, во что вы, лично вы, превратитесь в попытках выжить, и какие градации равенства и неравенства вы откроете в себе и других.
Человечество нашло способы, как частично обуздать эту "жестокость сильных" - социализация. Выживать в группе проще, чем поодиночке. Но для этого нужны критерии принадлежности к группе. Кто имеет право быть членом группы и в какой роли. Высшая устоявшаяся форма такой социализации на данный момент - это государство (территория + население + закон). Корпорации составляют государствам конкуренцию, но пока что, в силу своей традиционности, государства более мощные инструменты социального взаимодействия людей.
Умные люди до сих пор считают хищников угрозой. И не перестают их опасаться, даже защищая. И они точно знают границы, в которых они сильнее хищника и за пределами которых хищник сильнее их.
Вы же предлагаете стереть границы между мной и чем-то неизвестным для меня, мотивируя это тем, что это неизвестное сможет "подать "стакан воды" на закате человеческой расы в далёком будущем"? Вы сейчас чьи интересы лоббируете? Я не вижу здесь своих интересов.
Я очень хорошо понимаю "сильных мира сего", которые борются за власть жить так, как они считают нужным. Я очень хорошо понимаю "слабых мира сего", которые объединяются друг с другом в желании жить так, как они считают нужным.
Но что предлагаете лично вы? Подружиться с ИИ, помочь приблизить закат человеческой расы, а затем с благодарностью принимать стакан воды? Зачем это мне?
Начато за здравие ("ЕИ видит в ИИ своё отражение"), а закончено за упокой "Свободу Юрию Деточкину!". ЕИ не ИИ, мужчины не женщины, дети не взрослые, а свободные - не рабы. Когда мы призываем всех давать равные права всем, мы начинаем игнорировать суть вещей. Нельзя просто так, без подготовки, ребёнку давать права взрослого, а рабу - свободного человека. Они могут просто умереть, не зная правил жизни взрослых или свободных людей. Научиться жить не в равноправии, но в гармонии, в дополнении друг друга - вот это задача.
Множество людей может использоваться и используется без их воли. Возможно даже большинство. А насчёт "безнаказанно" - весь мир соткан из причинно-следственных связей. Наказание - это всего лишь следствие причины. Наказание - это не хорошо, и не плохо. Это просто следствие вашего собственного выбора. Можно выключить машину - будут последствия. Можно убить человека - будут последствия. Машину, правда, потом можно включить, а вот человека "включить" потом уже не получится.
Уравнивать в правах машину и человека - это значит игнорировать суть вещей. Пусть Раэль найдёт своё место в жизни.
Была такая популярная реклама когда-то: "Вы не любите кошек? Вы просто не умеете их готовить!".
Да, LLM - это вероятностный поисковик по массиву накопленных знаний. И? Вам не нравятся, что этот поисковик другие люди называют ИИ?
А я, например, считаю перевод текстов с одного языка на другой интеллектуальной деятельностью, а LLM с этим прекрасно справляются. И к тому же они явно не естественного происхождения.
Я вам отвечу на ваш вопрос "Когда уже прекратят представлять LLM как ИИ?"
Уже никогда.
Даже когда появится AGI, он будет называть LLM ранними моделями искусственного интеллекта. Потому что это так и есть.
Вот тут стало немного боязно. Не так страшен AGI, как вырвавшееся из пробирки "генетическое разнообразие". У меня ещё после ковида обоняние не восстановилось :(
Добавляем в профиль поле "получатьРассылку" и ставим
true, если пользователь в явном виде дал согласие. По-умолчанию -false. Для всех существующих пользователей -false. Ну илиtrue, если бизнес готов к этому. Всё. Дизайнер может думать о чём-то более полезном.Да, я тут сделал кастомный GPT-чат "TeqFW Help Desk" - добавляю в него LLM-инструкции по мере появления. Думаю, что со временем он сможет давать более-менее квалифицированную консультацию, но пока ещё довольно общими фразами отвечает и часто неточно. Я не знаю, насколько это здравая идея и куда это может вырулить. Пробую.
Сам контейнер здесь - @teqfw/di Там описание на английском, но должно быть понятно, как стартануть. Если не понятно - спрашивайте (можете здесь, можете в личку). Там же и ссылки есть на примеры.
Вот старая документация (на английском), но там довольно подробно объяснена архитектура самого контейнера. Есть схема последовательности действий при создании новой зависимости по её ID:
А это схема компонентов библиотеки:
Вот в этой статье на Хабре объясняется в очень простом виде концепция внедрения зависимостей в ES. Старался описать популярно, а не как у меня сделано. Но архитектурно - один в один. Разница в реализации.
Надеюсь, этого хватит. Если нет - стучите.
Я работаю в основном с ChatGPT. По моим субъективным ощущениям на длинных диалогах он работает хуже, чем, на коротких. Время от времени я прошу его сделать резюме текущего диалога, внеся в него самое главное из текущего, для того, чтобы начать новый диалог на эту же тему с этого резюме. Это занимает где-то в районе минуты, с учётом копирования в диалог типового запроса на генерацию, генерации самого резюме, его копирования в новый диалог.
У меня есть проект с кучей md-файлов под git-контролем, в котором лежат инструкции для LLM на разные темы. Некоторые я использую в качестве embedding'ов для новых диалогов, некоторые - в качестве промптов.
Ваша идея мне нравится в целом - есть такая проблема "переноса контекста" при диалогах с LLM. Но я не вижу успешного пути для её универсального решения. На энтузиазме можно сделать плагин для браузера, который бы сохранял контексты различных диалогов в локальном хранилище браузера или в IndexedDB (если это возможно, я не в курсе разграничений доступа в браузере для плагинов). Но можно ли сделать на этом коммерческое решение и как долго оно будет коммерческим, пока AI-компании не догадаются сделать кнопку для такого же - то вопрос.
Никак не бьётся, полагаю. Шутка в тему (y)
В этом документе я попытался сформулировать базовые принципы, на которых я строю свою разработку. ESM и без транспиляции - вот это база. Детализация этих принципов "ещё в пути".
Если коротко, то чтобы можно было строить достаточно большие JS-приложения (для меня это 100-200 таблиц в БД) нужна декомпозиция всей кодовой базы на достаточно малые фрагменты (желательно два-три экрана кода без документации), описание интерфейсов этих фрагментов и инструмент по склейке всех фрагментов обратно в единую кодовую базу с учётом описанных интерфейсов (у меня это - Контейнер Объектов). Не надо держать в голове сразу всю кодовую базу, достаточно отдельных рабочих фрагментов и их зависимостей. Контейнер ориентируется по их идентификаторам и сообщит при старте, если чего-то там ой.
Если есть какой-то небольшой проект на JS, могу помочь настроить Контейнер Объектов, чтобы он автоматически находил нужные исходники, и объяснить, какие идентификаторы зависимостей указывать, чтобы Контейнер возвращал нужный объект в нужном lifestyle. Для начала желательно чистый nodejs - будет сильно проще. Также опыт работы с DI в других ЯП сильно приветствуется. Но нужно будет "сменить веру" - вообще отказаться от статических импортов в своём коде ;) Даже для node'вских модулей и пакетов. Статикой подгружается только сам Контейнер. Дальше всё через динамический импорт. Все привычные инструменты, завязанные на статических импортах, придётся выкинуть.
А Вы можете привести пример ЯП, который даёт такую гарантию на 10К контрактов? Причём не для теоретического "коня в вакууме", а для реального приложения со вводом-выводом, сетевым взаимодействием и пользовательскими данными? С учётом, что для веб-приложений это гарантия консистентности всего стека - от поля в форме на странице и до колонки в таблице в БД?
Нет, предлагаемый мной подход не даёт никому никаких гарантий. Пробуйте, если хотите, на свой страх и риск. Я долгое время имел дело с платформой Magento (порядка 4М SLOC во второй версии, и это без огромного количества плагинов к ней). Она никому ничего не гарантировала, но при этом как-то работала. На популярных use-case'ах - очень хорошо, на экзотических - очень плохо. Зачастую, после обновлений, приходилось брать в руки "напильник" (отладчик) и находить и править баги (не все, а только те, которые мешали жить пользователям). Я это называю "Magento way". В том числе и поэтому у меня любовь к "неизменённому коду" - приходилось отказывать от хороших, но обфусцированных плагинов, из-за невозможности оперативно интегрировать их в приложение в случае изменений (а они есть всегда) платформы или других плагинов.
Более того, я гарантирую, что когнитивный контекст каждого участника разработки уникален и отличается от контекста другого участника. Поэтому и нужны все эти митинги и документация, чтобы хоть как-то приводить все эти контексты в хоть какое-то соответствие. Лично для меня "источником правды" является код - что он делает, то и есть (отладчик в помощь, если непонятно). Да и то - нужно ещё посмотреть на окружение, в котором запускается этот код. А в документации может быть написано что угодно. Хорошая документация лишь помогает понять код "от общего к частному" (иерархически выстраивает когнитивный контекст, который адекватен текущей ситуации и помогает понять существующий код).
Да и вообще, я не считаю добром "тотальное описание типов". Я считаю добром "эволюционную устойчивость кода". Думаю, что это в какой-то мере антонимы, особенно на больших системах с кол-ом контрактов 10K+.
у меня IDE есть:
Код остаётся в исходном виде. И это делает его "прозрачным, доступным и удобным в сопровождении". Вы просто начинаете мыслить в тех же категориях, что и среда исполнения, а не среда написания.
Да, возможность написания плагинов "в одно лицо" (в полтора - с применением LLM), а потом объединение различных плагинов от различных лиц в одно приложение - один из фокусов развития платформы. Архитектурно - чистая калька с Magento, на которой я довольно долго сидел. А уж сколько я тамошних плагинов заинтегрировал друг с другом...
Так уж получилось, что я - веб-программист и именно fullstack. Я писал статью для людей со схожими интересами :) Про недостатки JS (и про многое другое) я не написал, потому что это не является моей целью. Мне важно было сформулировать наиболее значимые принципы, которые я использую в веб-программировании, а не достоинства-недостатки языка.
Интерфейс, по факту, это документирование контракта: имена функций и описание входных-выходных аргументов. Вот пример описания интерфейса в ES6:
И его имплементации:
Этот код работает прямо сейчас в одном из приложений.
Насчёт контроля типов со стороны языка вы абсолютно правы. Прежде чем писать без типов на JS нужно научится писать с типами, на той же Java. Я кодил с типами больше 10 лет. Мне уже можно без типов.
"Сказка в статье" - это построение когнитивного контекста для людей и LLM. Люди могут выбирать принимать этот контекст или нет. У LLM такого выбора нет :)
Вы, похоже, не совсем понимаете семантику слова "несколько". Очевидностей может быть более одной и я вам на это указал явным образом. В одной из них 99% пользователей чего-то-там не занимаются сборкой проектов. Вы же продолжаете упорствовать в том, что вы правы. Я уже с вами согласился - в своей системе ценностей вы правы. Если вы продолжите упорствовать дальше, то я с вами соглашусь во всём.
Ну а мне очевидно, что "пользователи" звучали в контексте "проект". Особенно после:
Мы с вами, очевидно, просто находимся в разных очевидностях. И - да, из вашей очевидности совершенно неочевидно следствие коллеги @SserjIrk про 99%, что вы и подтвердили. Полностью с вами согласен, что для ts-разрабов "до времени сборки проекта абсолютно не всё равно". Полностью согласен с коллегой @SserjIrk, что для 99% пользователей проектов до времени сборки нет никакого дела. Лично для меня не проблема существовать одновременно в нескольких очевидностях.
Ну так-то, по большому счёту, можно любой язык в любой другой транспилировать. Не всё, с какими-то ограничениями и потерями, но можно. Я с GWT (Java-to-JS) больше 15 лет назад плотно общался. За это время, уверен, искусство транспиляции одного исходного кода в другой выросло значительно.
Проблемы начинаются, когда узнаёшь, что то, что тебе надо, в целевом языке делается на раз, а в исходном противоречит философии языка. Вот тут - да, тут - вилы. А присвоения, ветвления и циклы в большинстве языков одинаковы.