Я вам о том что ваш dsl можно было сделать без изобретения своего ЯП. Вы мне о том, что ваш продукт дешевле SAP и 1С. Ну дешевле. Вы молодцы. Dsl без изобретения языка - это когда вы берёте подмножество существующего яп и даёте прикладниками его. Без потери выразительности можно было использовать и linq-синтаксис C#, перегрузив SelectMany и Select и компутейшны из F# и kotlin dsl, но вы написали своё. Я не увидел ни одного комментария вида "о, да точно, вот такого не хватало" в оригинальной статье, но вы продолжаете настаивать, что ваш язык лучше. На мой вкус он ничем не примечательный и никаких революций вы не произвели. Tool support вашего dsl хуже, чем у mainstream-языков. Вы утверждаете, что "он понятнее для не программистов", но это бездоказательно. Объясните, почему нельзя добиться тех же результатов используя вашу платформу и один из языков на выбор в качестве dsl: Kotlin, C#, F#, TS, Python, Ruby. Я могу изобразить аналогичный вашему код на каждом из этих языков. А копипастить по примеру и обезьяну можно научить.

Может поэтому пошёл такой бум на автоматизацию медицины?

Справедливо:)

У Kotlin'а уровень абстрагирования не сильно выше, чем у Java

Либо вы плохо знакомы с Kotlin, либо у нас разное понимание абстрагирования. В Java вы вот такое не напишите. Рекомендую еще посмотреть на сигнатуры функций из примера на главной страницы Ktor. Опять таки уровень абстракции сильно выше, чем в Java. Ну и вишенка на торте - корутины.

Если все-таки когда-нибудь доделают expression trees, то будет комбинация полностью покрывающая заявленные вами преимущества: декларативность - dsl. Возможность очень сильно перколбасить байткод (и не только для асинхронного взаимодействия) - корутины. Эффективная трансляция в SQL - деревья выражений. Только вот такой DSL будет на 100% нативным для JVM и при желании его допишем любой программист, знакомый с Kotlin, а не с вашим особым языком. Все подсветки синтаксиса, автокомплишны и т.д. тоже будут работать автоматом. Пока expression trees нет, есть Spring Data или JOOQ, которые такие же декларативные, как ваш "особый уникальный невероятный (без регистрации и смс) язык".

Аналогичные DSL без изобретения языка можно довольно быстро организовать на .NET-стеке с помощью уже упомянутых деревьев выражений и LINQ или вообще F#'а. Нет принципиально никакой разницы - учить ограниченное подмножество существующего языка или ваш язык. Ваша дискуссия с@lairв оригинальном треде - тому пример. Просто, видимо, у вас сильная эмоциональная связь с вашим детищем, которая не позволяет объективно его оценивать.

А формочки и роли запускает их облако или там какой-то код генерируется (исходный или байткод), который потом запустить можно?

А потом все эти "тесты" сломаются и их выкинут как нечитаемой и неподдерживаемое гуано.

В комментариях к оригинальной статье уже написали "что вы делаете не так". Вы пишите на странном велосипеде, который никто кроме вас поддерживать не сможет. Не ясна рыночная ниша этого продукта. Но вам нравится и никто не сможем вам запретить. Я бы ни за что для себя такую систему не поставил, потому что нет в мире достаточного количества программистов на этой "платформе". Если говорить про dsl на jvm-стеке, то в Kotlin прекрасный dsl. Почему не использовать его?

Мне кажется, что low code в ближайшие несколько лет так и останутся игрушками для заказа пиццы. Зато верю в GraphQL и докер. Сделал бекенд, запакаковал в контейнер, подключил к гейтвею через федерацию. Поменьше баз данных и очередей только создавать и баундед контексты правильно определять, но это уже совсем другая история.

Нет, это про те самые санкции, которые диктаторам "все ни по чем"

Про словари я тоже спрашиваю) Но не напрямую, а про природу вот этого ворнинга. А если в ваш список вопросов добавить почему у ConcurrentDictionary метод называется GetOrAdd, то там и volatile и lock можно захватить и try pattern. В общем, все в этом методе прекрасно для вопроса на собеседовании. Но это на любителя уже.

Против "расскажите о сборке мусора в .NET" я ничего не имею. Просто уже не первый раз на Хабре вижу комменты в духе "от меня требовали рассказать за 30 секунд чуть ли не весь gc internals". Судя по этой статье, я уже не уверен, что дела именно так обстояли. Может и правда "расскажите о сборке мусора в .NET" люди воспринимают как "Расскажите про gc internals в деталях"

Не все могут учиться самостоятельно. Кроме того, обилие информации это и + и - одновременно. Выбрать "не ерунду" начинающему разработчику может быть сложно. Этим и пользуются "вITшные" курсы.

Мне кажется, что сейчас все накушались курсов уже и скоро начнет формироваться дорогое платное высшее образование для IT. Как в США: родился ребенок - родители открыли счет на колледж.

Цель могла быть даже "работать на работе, которую любишь", а "нужные вещи для работодателя" могли бы быть средством:)

Я просто не очень пониманию как глубокие знания об устройстве GC могу пригодиться кому-то, кроме тех, кто пишет GC. Я понимаю, если вопросы будут формулироваться как: "а вот тут были таски, а мы поменяли на валью таски, зачем бы такого захотелось?", "а вот тут у нас время отклика 50мс, но есть редкие, но регулярные спайки и только на проде, а тесты таких деградаций не показывают, а что это может быть?". Про span'ы или async enumerable если бы спросили, тоже понимаю. Т.е. если идут от задачи конкретной, а не эрудиции ради эрудиции. Мы когда опросник составляли, поняли, что ну не надо при решении наших задач знать детали GC, поэтому в итоге вообще про GC ничего не спрашиваем. Если выяснится, что человек плавает, пойдет читать/смотреть Кокосу. async/await вот спрашиваем, потому что с ним регулярно косячат.

На последнем DotNext'е мне понравилась шуточная рекомендация. Если спрашивают про GC отвечай баззвордами: мемори трафик, аллокации, поколения, LOH, POH, карточный стол. Чтобы интервьюер сразу понял, что ты шаришь :) Если про детали говорить, то Pro .NET Memory Management - несколько тысяч страниц. Курс Кокосы на YouTube еще часиков двадцать. Вот это прям важные и нужные вложения времени, которые не стоит заменить на, скажем, знания в области программной инженерии, рефакторинга, да тех же софт скиллов, ни к ночи помянутых.

ИМХО такие вакансии надо помечать "нам реально надо, повтори кишки". Следить за тем не поменялись ли реализации стандартной библиотеки от версии к версии платформы - развлечение на любителя.

Че так все по этому сборщику с ума сошли? Реально, что-ли на собесах это спрашивают? Что за больные люди? Или там не детали спрашивают, а просто "расскажите что такое gc и опишите принципы его работы" и народ такой вопрос считает "ненужной фигней"?

Там немного другая история. Async в f# - это computation expression (ближе к корутинам в Kotlin, но немного другая штука). В c# ввели именнно ключевые слова в язык, которые копипастнули в is и python. Ну и f# все же не mainstream-язык. Можно по этой логике добавить, что IO в хаскеле вообще с прошлого века

Да, про Last без Where загнался, вы правы. Я имел в виду именно вариант, когда предикат записан отдельным Where, чтобы на выходе IEnumerable был

.Where(predicate).Last();

Я по этому поводу согласен с @lair, что можно словить нежданчик. Может имело смысл сделать отдельную перегрузку для IList, чтобы такие вещи были более явными.