Неудачный пример. Я, например, могу выключить газ с закрытыми глазами. Да и вы тоже. Попробуйте просто. С электроподжигом я могу и включить газ с закрытыми глазами - горящий газ шумит по-другому. Я, когда дома чайник ставлю, никогда специально под него не заглядываю - ни когда включаю, ни когда выключаю. У меня плита с электроподжигом.
Или у вас действительно были случаи, когда вы газ выключили, а он продолжил гореть? Я лично с таким не сталкивался ни разу.
Интересный взгляд. Плюсанул. Мне кажется, что заполнять своё контекстное окно нужно "маловероятным". LLM тяготеют к высоким вероятностям, а низкие вероятности остаются не при делах.
Свершилось то, о чём предупреждал Иоанн Богослов в своих "откровениях":
Но, как ты тепл, а не горяч и не холоден, то извергну тебя из уст Моих.
Это как раз про вероятности. "Кожаным" придётся уходить в сторону отклонений (холоден или горяч), т.к. срединная ниша (тёплый) теперь занята "силиконовыми".
Это, разумеется, шутка, но в каждой шутке есть только доля шутки. IMHO, творческая составляющая развития (эволюция) - за человеком, стабилизирующая (удерживающая) - за ИИ.
Ключевая проблема в том, что при разработке приложений вы "думаете" не на том языке, на котором "думает" компьютер при их выполнении.
В природе существуют транспиляторы в JavaScript, как минимум, для следующих языков: CoffeeScript, Dart, Kotlin, Scala, F#, Clojure, Elm, PureScript, Haxe, Go, Java, Python, Ruby, ...
Простую "программу для браузера" можно написать на любом из этих языков, но её придётся транспилировать в JS (или WASM) - браузеры просто не понимают ничего, кроме JavaScript и WASM (но WASM уже плохо понимает человек).
Каждый из перечисленных выше языков обладает какими-то преимуществами и какими-то недостатками, вытекающими из преимуществ. При транспиляции из одного языка в другой недостатки каждого языка суммируются, а преимущества исходного языка просто теряются.
Так вот, чем TypeScript кардинально лучше любого из этих языков? Тем, что похож на JavaScript больше любого другого? Больше любого другого на JS похож сам JS - в нём недостатки только его самого, которые хоть как-то компенсируются его достоинствами.
TS можно и нужно было использовать вместо JS до появления ES6 - c 2012 по 2015 год. А потом качественная разница между ними лишь уменьшалась.
Если вам удобно кодировать "программы для браузера" на TypeScript - пожалуйста, кодируйте на TypeScript. Другим удобно это делать на других языках (я перечислил только часть). Браузер всё равно понимает лишь JavaScript и WASM.
Когда я пишу "программы для браузера", я предпочитаю делать это на максимально близком ему языке, чтобы не привносить в runtime недостатки других ЯП. Только и всего.
А вы-то сами можете "детерминированно генерировать код"? Не на уровне "Hello, World!" или "ToDo List", а на уровне приложения хотя бы на пару тысяч LOC? Каковы ваши собственные пределы детерминированности?
Я когда-то, в первой половине 90-х, изучал ассемблер и писал на нём работающие программы. Не то, чтобы я читал с листа машкоды, но разбирался с помощью справочника, что именно там написано. А потом мне как-то стало плевать на сохранность этого навыка и я ушёл в сторону ЯП высокого уровня - сначала C/Pascal, потом C++, потом Java, а потом вообще PHP и JS.
Буквально вчера вечером я попросил агента исправить одноразовое приложение на JS, которое такой же агент создавал 10 месяцев назад для мониторинга сайта объявлений и которое проработало несколько недель, пока не перестало быть нужным. Теперь надо было мониторить другую категорию объявлений с другой структурой. В этом приложении есть веб-сервер для регистрации пользователей на получение push-уведомлений и сервис, который опрашивает сервер объявлений на предмет появления новых, после чего отправляет push-уведомление всем зарегистрированным пользователям. Я ж говорю, чисто одноразовое приложение под текущую задачу.
Так вот, я полез читать код, который там нагенерён - не помню я через 10 месяцев, что там вообще. Потом плюнул и просто спросил агента - что это и как оно работает. Через минут 5 у меня в памяти была восстановлена картина в общих чертах. Ещё минут 10 мы с агентом переключались на новую категорию объявлений и обновляли библиотеки, после чего я минут 20 восстанавливал окружение, которое я снёс за ненадобностью - веб-сервер, DNS, systemd, ... Сейчас это приложение уже крутится и мониторит новую категорию.
В код я так больше и не заглядывал. Не пригодилось.
Я в курсе, что не во всех сферах человеческой деятельности такой подход применим. Я даже могу согласиться, что во многих сферах традиционного программирования такой подход не применим. Но такой подход открывает ниши, где неприменим уже традиционный подход "с чтением кода и написанием его вручную".
Кстати, буквально вчера стучал рекрутёр с вопросом, а могу ли я всё ещё работать с Lotus Notes? А я уже лет 15-20, как с ним не работаю никак. Не сохранил я этот навык, как и множество других, когда-то полезных - умение администрировать машины с MS-DOS и Windows for Workgroups, NT4, XP, Win2K, OS/2 Warp, Novell Netware, Solaris, Slackware, RedHat/Fedora, писать проги под MS Office и Lotus Notes/Domino, сервлеты под Tomcat, утратил навыки программирования портлетов для Liferay и их интеграции с Intalio BPMS, я больше не программирую на Clarion / C / LotusScript / VisualBasic / Java и почти уже не программирую на PHP и начал забывать Magento. У меня много утраченных навыков и много приобретённых. Одним больше, одним меньше...
Да, у вас такая сфера деятельности, где нужны работающие и проверенные практикой подходы. Вангую, что к вам ИИ-кодинг придёт позже других и в уже достаточно стабильном виде :) Ну а эксперименты с ИИ будут проводиться в других сферах.
То что работает у вас, не факт что сработает в другой сфере, не только моей.
Ладно, давайте расширять. Вот JS-код. Во всех исходниках всего пакета (./src/) нет ни одного статического import'а. А там порядка 20 файлов. Тем не менее, пакет рабочий и используется в составе других пакетов (например, github-flows-app).
Это называется "late binding". В таком виде (без статических импортов) JS-код становится изоморфным - может работать и в браузере, и на бэке без изменений. Юнит-тестирование такого кода становится детской игрой, так как можно подменить моком любую зависимость, вплоть до node-библиотек.
Этот подход пришёл из того самого "энтерпрайза", который вы пренебрежительно называете "Ынтырпрайз". В кодовой базе Magento Open Source 2.4.x свыше 2 млн. строк на PHP, а ещё под 0.5 млн - на JavaScript (не TypeScript!). В базовом наборе платформы порядка 200+ модулей, а сторонние разработчик дают возможность доставить в базу ещё свыше 2К модулей и одному Богу известно, сколько там строк кода. И весь этот "зоопарк" способен крутиться согласованно и на фронте, и на бэке, благодаря технологиям "Ынтырпрайза", в том числе и позднему связыванию.
И тот же WebStorm использует TypeScript Language Server для валидации типов
WebStorm появился в 2010 году - за два года до TypeScript'а. В нём есть отдельно настройки для JavaScript и для TypeScript. Да, для валидации типов в TypeScript IDEA может использовать TS Language Server. Но его можно отключить и писать на чистом JS.
В IDEA JS можно использовать без TS
Это означает: больший размер бандла (нет минификации и удаления неиспользуемого кода),
Минификации JSDoc не мешает - можно выкинуть все JSDoc'и и код остаётся рабочим. А неиспользуемого кода здесь нет в принципе - связывание идёт в runtime.
Да, для TS есть своя ниша - "галеры". Создаётся ощущение контроля за ситуацией. Типа, мы "натянули типы" на JS. Но - нет, не натянули. Их там как не было, та и нет. Откройте DevTools в браузере по F12 и убедитесь сами. Типы есть только в вашем IDE и лишь до транспиляции.
Я пять лет назад уже публично пояснил, почему я предпочитаю JS. С тех пор не особо что изменилось. Вернее, поводов использовать TS становится всё меньше. А ИИ-агенты - так это вообще повод TS не использовать. Им-то зачем лишний раз код транспилить при рефакторинге? Экономия токенов идёт от понимания моделью контекста задачи, а не от количества символов, и JSDoc здесь как раз к месту.
А если пользователь находит баг, который стоит миллионы для компании?
Это значит, что остальные способы проверки работоспособности продукта не сработали и баг попал в прод.
Нет, это значит остальные способы проверки работоспособности оказались недостаточными.
А разве “оказались недостаточными” по факту не означает “не сработали”? IMHO, как раз именно это и означает.
Нет, не означает. Одно дело если вы это тестировали и баг просочился именно там, где должен был отловить тест (ложно положительный результат), и другое дело когда это даже не проверяли.
ОК, я вполне могу принять вашу точку зрения (если “ложно положительный” - то “не сработали”, если “не проверяли” - то “недостаточные”). Но у меня картина мира попроще: баг на проде - облажались при тестировании. Ну так мне и не нужно в куче бумажек расписывать откуда-куда-что. В e-commerce как-то всё попроще, чем на ж/д.
Это значит, что остальные способы проверки работоспособности продукта не сработали и баг попал в прод. Что лишь подтверждает тезис, что самое надёжная проверка - на конечных пользователях.
"бест" - это "лучший". А я писал про "надёжный". Это "рилайэбл".
И если вы немного пораскинете мозгами, то тоже придёте к такому выводу: "самый надёжный метод проверки работоспособности продукта - на конечных пользователях".
Мы, наверное, разное вкладываем в понятие SDD. Я, например, вкладываю в это понятие то, что при хорошо написанной документации, код можно доверять (пере)генерировать агенту. Но "спеки" в этом случае должны описывать не только продукт с точки зрения бизнеса, но и используемые технологии, платформы, проектные соглашения и т.п.
Но поскольку эксплуатировать дальше продукт без чтения кода нельзя
Можно. И вы сами это делаете. У ИТ-сообщества богатый опыт использования сторонних библиотек (те же .dll в windows и .so в linux). Сборщики типа maven, composer, npm - это из этой же оперы. Вам необязательно лезть в код, чтобы использовать продукт. Достаточно контракта.
Есть много других способов. Самый надёжный из которых - конечные пользователи. Я долгое время работал с Magento, строил на её базе магазины и интегрировал в них различные расширения сторонних производителей. Очень любопытный опыт, я вам скажу. Так вот, "Magento way" - это тестирование продукта на конечных пользователях. Ну, это я так его назвал - Magento way. Потому что как интегратор я видел, что типовые сценарии работают как часики, а вот шаг влево или вправо - болото. И тикетов в Magento висела гора, я сам поставил не один десяток. И висели тикеты годами, даже те, к которым PRы были с решениями на две строчки. А платформа, тем не менее жила и процветала, одно время была вообще самой популярной в e-commerce.
Так вот, Magento way - и есть самый надёжный способ проверки работоспособности продукта. Остальные лишь помогают минимизировать возможный ущерб от "проверки пользователем". Включая ваши варианты с тестами и анализом кода через ИИ.
Согласен с @rg_software SDD - это то, как должна выглядеть разработка в идеале. И не важно, кто там "под капотом" - "кожаные" или "силиконовые".
"План эксперимента", так-то, тоже можно считать своего рода спецификацией. А удачные бизнес-приложения сейчас вообще никогда писать не заканчивают (тот же Youtube, Facebook, Amazon, ...). Так что картинка "написал спеку, а по ней просто код пишешь" - это всего лишь маленький фрагмент жизненного цикла приложения.
И это... я сейчас так и делаю - пишу документацию (спецификации), а по ним агент код генерит. Потом меняю документацию и агент меняет код. Ну и т.д.
Народ пока ещё не привык к тому, что код можно не читать. Вообще. Работоспособность продукта можно и нужно проверять не чтением кода. Но это знают product owner'ы, а не девелоперы. Вот поэтому первых станет больше, а вторых - меньше.
А для чего вам нужен TS? Вот всё то же самое делает JS, только без транспиляции и source maps. Вы, когда в консоли браузера код для исполнения вбиваете, вы JS'ом пользуетесь. Ну и зачем вам транспилятор, который в конце-концов переведёт ваш код в JS?
И чем TS лучше Java в этом случае? Я несколько лет кодил на GWT (Java-to-JS). Java вообще очень красивый, инженерный язык. Смысл мне кодить на TS, если я больше десяти лет кодил на Java? Мне можно уже сразу на JS кодить. Без посредников.
А так-то можно и для brainfuck'а свой транспилятор написать, чтобы в JavaScript перекодировалось.
вот только harness(пояс) может быть пеньковой веревкой, а может быть тактическим ремнем.
Но если у тебя в руках АК-74, то на поясе должны висеть магазины с патронами 5,45-мм и не важно - тактический это ремень или пеньковая верёвка :)
все остальное задача машины: спросить, что хочешь, предложить варианты, сопроводив их комментариями об эффективности и ограничениях, оформить и сохранить постановку задачи. При этом не забыв про Liskov Substitution и декларативный код. :)
Я имел в виду, что задача человека - научить машину вот этому "всему остальному" :) А так - да, в идеале машина должна мочь вытащить ТЗ и из Эллочки-людоедки.
Неудачный пример. Я, например, могу выключить газ с закрытыми глазами. Да и вы тоже. Попробуйте просто. С электроподжигом я могу и включить газ с закрытыми глазами - горящий газ шумит по-другому. Я, когда дома чайник ставлю, никогда специально под него не заглядываю - ни когда включаю, ни когда выключаю. У меня плита с электроподжигом.
Или у вас действительно были случаи, когда вы газ выключили, а он продолжил гореть? Я лично с таким не сталкивался ни разу.
А вы правда верите, что качество кода зависит от того, что на него кто-то посмотрел?
Интересный взгляд. Плюсанул. Мне кажется, что заполнять своё контекстное окно нужно "маловероятным". LLM тяготеют к высоким вероятностям, а низкие вероятности остаются не при делах.
Свершилось то, о чём предупреждал Иоанн Богослов в своих "откровениях":
Это как раз про вероятности. "Кожаным" придётся уходить в сторону отклонений (холоден или горяч), т.к. срединная ниша (тёплый) теперь занята "силиконовыми".
Это, разумеется, шутка, но в каждой шутке есть только доля шутки. IMHO, творческая составляющая развития (эволюция) - за человеком, стабилизирующая (удерживающая) - за ИИ.
Ключевая проблема в том, что при разработке приложений вы "думаете" не на том языке, на котором "думает" компьютер при их выполнении.
В природе существуют транспиляторы в JavaScript, как минимум, для следующих языков: CoffeeScript, Dart, Kotlin, Scala, F#, Clojure, Elm, PureScript, Haxe, Go, Java, Python, Ruby, ...
Простую "программу для браузера" можно написать на любом из этих языков, но её придётся транспилировать в JS (или WASM) - браузеры просто не понимают ничего, кроме JavaScript и WASM (но WASM уже плохо понимает человек).
Каждый из перечисленных выше языков обладает какими-то преимуществами и какими-то недостатками, вытекающими из преимуществ. При транспиляции из одного языка в другой недостатки каждого языка суммируются, а преимущества исходного языка просто теряются.
Так вот, чем TypeScript кардинально лучше любого из этих языков? Тем, что похож на JavaScript больше любого другого? Больше любого другого на JS похож сам JS - в нём недостатки только его самого, которые хоть как-то компенсируются его достоинствами.
TS можно и нужно было использовать вместо JS до появления ES6 - c 2012 по 2015 год. А потом качественная разница между ними лишь уменьшалась.
Если вам удобно кодировать "программы для браузера" на TypeScript - пожалуйста, кодируйте на TypeScript. Другим удобно это делать на других языках (я перечислил только часть). Браузер всё равно понимает лишь JavaScript и WASM.
Когда я пишу "программы для браузера", я предпочитаю делать это на максимально близком ему языке, чтобы не привносить в runtime недостатки других ЯП. Только и всего.
А вы-то сами можете "детерминированно генерировать код"? Не на уровне "Hello, World!" или "ToDo List", а на уровне приложения хотя бы на пару тысяч LOC? Каковы ваши собственные пределы детерминированности?
Я когда-то, в первой половине 90-х, изучал ассемблер и писал на нём работающие программы. Не то, чтобы я читал с листа машкоды, но разбирался с помощью справочника, что именно там написано. А потом мне как-то стало плевать на сохранность этого навыка и я ушёл в сторону ЯП высокого уровня - сначала C/Pascal, потом C++, потом Java, а потом вообще PHP и JS.
Буквально вчера вечером я попросил агента исправить одноразовое приложение на JS, которое такой же агент создавал 10 месяцев назад для мониторинга сайта объявлений и которое проработало несколько недель, пока не перестало быть нужным. Теперь надо было мониторить другую категорию объявлений с другой структурой. В этом приложении есть веб-сервер для регистрации пользователей на получение push-уведомлений и сервис, который опрашивает сервер объявлений на предмет появления новых, после чего отправляет push-уведомление всем зарегистрированным пользователям. Я ж говорю, чисто одноразовое приложение под текущую задачу.
Так вот, я полез читать код, который там нагенерён - не помню я через 10 месяцев, что там вообще. Потом плюнул и просто спросил агента - что это и как оно работает. Через минут 5 у меня в памяти была восстановлена картина в общих чертах. Ещё минут 10 мы с агентом переключались на новую категорию объявлений и обновляли библиотеки, после чего я минут 20 восстанавливал окружение, которое я снёс за ненадобностью - веб-сервер, DNS, systemd, ... Сейчас это приложение уже крутится и мониторит новую категорию.
В код я так больше и не заглядывал. Не пригодилось.
Я в курсе, что не во всех сферах человеческой деятельности такой подход применим. Я даже могу согласиться, что во многих сферах традиционного программирования такой подход не применим. Но такой подход открывает ниши, где неприменим уже традиционный подход "с чтением кода и написанием его вручную".
Кстати, буквально вчера стучал рекрутёр с вопросом, а могу ли я всё ещё работать с Lotus Notes? А я уже лет 15-20, как с ним не работаю никак. Не сохранил я этот навык, как и множество других, когда-то полезных - умение администрировать машины с MS-DOS и Windows for Workgroups, NT4, XP, Win2K, OS/2 Warp, Novell Netware, Solaris, Slackware, RedHat/Fedora, писать проги под MS Office и Lotus Notes/Domino, сервлеты под Tomcat, утратил навыки программирования портлетов для Liferay и их интеграции с Intalio BPMS, я больше не программирую на Clarion / C / LotusScript / VisualBasic / Java и почти уже не программирую на PHP и начал забывать Magento. У меня много утраченных навыков и много приобретённых. Одним больше, одним меньше...
Да, у вас такая сфера деятельности, где нужны работающие и проверенные практикой подходы. Вангую, что к вам ИИ-кодинг придёт позже других и в уже достаточно стабильном виде :) Ну а эксперименты с ИИ будут проводиться в других сферах.
Полностью согласен.
Ладно, давайте расширять. Вот JS-код. Во всех исходниках всего пакета (./src/) нет ни одного статического import'а. А там порядка 20 файлов. Тем не менее, пакет рабочий и используется в составе других пакетов (например, github-flows-app).
Это называется "late binding". В таком виде (без статических импортов) JS-код становится изоморфным - может работать и в браузере, и на бэке без изменений. Юнит-тестирование такого кода становится детской игрой, так как можно подменить моком любую зависимость, вплоть до node-библиотек.
Этот подход пришёл из того самого "энтерпрайза", который вы пренебрежительно называете "Ынтырпрайз". В кодовой базе Magento Open Source 2.4.x свыше 2 млн. строк на PHP, а ещё под 0.5 млн - на JavaScript (не TypeScript!). В базовом наборе платформы порядка 200+ модулей, а сторонние разработчик дают возможность доставить в базу ещё свыше 2К модулей и одному Богу известно, сколько там строк кода. И весь этот "зоопарк" способен крутиться согласованно и на фронте, и на бэке, благодаря технологиям "Ынтырпрайза", в том числе и позднему связыванию.
WebStorm появился в 2010 году - за два года до TypeScript'а. В нём есть отдельно настройки для JavaScript и для TypeScript. Да, для валидации типов в TypeScript IDEA может использовать TS Language Server. Но его можно отключить и писать на чистом JS.
Минификации JSDoc не мешает - можно выкинуть все JSDoc'и и код остаётся рабочим. А неиспользуемого кода здесь нет в принципе - связывание идёт в runtime.
Да, для TS есть своя ниша - "галеры". Создаётся ощущение контроля за ситуацией. Типа, мы "натянули типы" на JS. Но - нет, не натянули. Их там как не было, та и нет. Откройте DevTools в браузере по F12 и убедитесь сами. Типы есть только в вашем IDE и лишь до транспиляции.
Я пять лет назад уже публично пояснил, почему я предпочитаю JS. С тех пор не особо что изменилось. Вернее, поводов использовать TS становится всё меньше. А ИИ-агенты - так это вообще повод TS не использовать. Им-то зачем лишний раз код транспилить при рефакторинге? Экономия токенов идёт от понимания моделью контекста задачи, а не от количества символов, и JSDoc здесь как раз к месту.
JSDoc появился в 1999-м, TS - в 2012-м.
Не вижу смысла дискутировать. У нас с вами очень разные картины мира. Мне будет неуютно в вашей, а вам - в моей. Останемся при своих.
ОК, я вполне могу принять вашу точку зрения (если “ложно положительный” - то “не сработали”, если “не проверяли” - то “недостаточные”). Но у меня картина мира попроще: баг на проде - облажались при тестировании. Ну так мне и не нужно в куче бумажек расписывать откуда-куда-что. В e-commerce как-то всё попроще, чем на ж/д.
А разве "оказались недостаточными" по факту не означает "не сработали"? IMHO, как раз именно это и означает.
Да, опытная эксплуатация - как раз об этом. О проверке пользователями.
Специальными пользователями!
Это значит, что остальные способы проверки работоспособности продукта не сработали и баг попал в прод. Что лишь подтверждает тезис, что самое надёжная проверка - на конечных пользователях.
P.S.
bug bounty hunting - пример такого тестирования
"бест" - это "лучший". А я писал про "надёжный". Это "рилайэбл".
И если вы немного пораскинете мозгами, то тоже придёте к такому выводу: "самый надёжный метод проверки работоспособности продукта - на конечных пользователях".
Мы, наверное, разное вкладываем в понятие SDD. Я, например, вкладываю в это понятие то, что при хорошо написанной документации, код можно доверять (пере)генерировать агенту. Но "спеки" в этом случае должны описывать не только продукт с точки зрения бизнеса, но и используемые технологии, платформы, проектные соглашения и т.п.
Можно. И вы сами это делаете. У ИТ-сообщества богатый опыт использования сторонних библиотек (те же .dll в windows и .so в linux). Сборщики типа maven, composer, npm - это из этой же оперы. Вам необязательно лезть в код, чтобы использовать продукт. Достаточно контракта.
Есть много других способов. Самый надёжный из которых - конечные пользователи. Я долгое время работал с Magento, строил на её базе магазины и интегрировал в них различные расширения сторонних производителей. Очень любопытный опыт, я вам скажу. Так вот, "Magento way" - это тестирование продукта на конечных пользователях. Ну, это я так его назвал - Magento way. Потому что как интегратор я видел, что типовые сценарии работают как часики, а вот шаг влево или вправо - болото. И тикетов в Magento висела гора, я сам поставил не один десяток. И висели тикеты годами, даже те, к которым PRы были с решениями на две строчки. А платформа, тем не менее жила и процветала, одно время была вообще самой популярной в e-commerce.
Так вот, Magento way - и есть самый надёжный способ проверки работоспособности продукта. Остальные лишь помогают минимизировать возможный ущерб от "проверки пользователем". Включая ваши варианты с тестами и анализом кода через ИИ.
Нет. Нет.
"Жизнь такова, какова она есть, и более никакова" (с)
Если изначально не сделали и не развили, значит не можно было.
Согласен с @rg_software SDD - это то, как должна выглядеть разработка в идеале. И не важно, кто там "под капотом" - "кожаные" или "силиконовые".
"План эксперимента", так-то, тоже можно считать своего рода спецификацией. А удачные бизнес-приложения сейчас вообще никогда писать не заканчивают (тот же Youtube, Facebook, Amazon, ...). Так что картинка "написал спеку, а по ней просто код пишешь" - это всего лишь маленький фрагмент жизненного цикла приложения.
И это... я сейчас так и делаю - пишу документацию (спецификации), а по ним агент код генерит. Потом меняю документацию и агент меняет код. Ну и т.д.
Народ пока ещё не привык к тому, что код можно не читать. Вообще. Работоспособность продукта можно и нужно проверять не чтением кода. Но это знают product owner'ы, а не девелоперы. Вот поэтому первых станет больше, а вторых - меньше.
А для чего вам нужен TS? Вот всё то же самое делает JS, только без транспиляции и source maps. Вы, когда в консоли браузера код для исполнения вбиваете, вы JS'ом пользуетесь. Ну и зачем вам транспилятор, который в конце-концов переведёт ваш код в JS?
И чем TS лучше Java в этом случае? Я несколько лет кодил на GWT (Java-to-JS). Java вообще очень красивый, инженерный язык. Смысл мне кодить на TS, если я больше десяти лет кодил на Java? Мне можно уже сразу на JS кодить. Без посредников.
А так-то можно и для brainfuck'а свой транспилятор написать, чтобы в JavaScript перекодировалось.
Но если у тебя в руках АК-74, то на поясе должны висеть магазины с патронами 5,45-мм и не важно - тактический это ремень или пеньковая верёвка :)
Я имел в виду, что задача человека - научить машину вот этому "всему остальному" :) А так - да, в идеале машина должна мочь вытащить ТЗ и из Эллочки-людоедки.