Я вам о том что ваш 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, чтобы такие вещи были более явными.
Но там внутрях уже разная реализация через апкасты! Например, array.Count() не будет перечислять массив, а просто вернёт Length.
Пока вы не добавили предикат
Кстати, реализация First и Last нарушать LSP не может в принципе, потому что LSP — требование к иерархии типов, а не к внешним операциям над ними.
Это терминологическая демагогия. Каким термином вы предлагаете кратко описывать ситуацию, когда метод работает с одним специализированным типом из иерархии, но не работает с другим?
Я вам о том что ваш dsl можно было сделать без изобретения своего ЯП. Вы мне о том, что ваш продукт дешевле SAP и 1С. Ну дешевле. Вы молодцы. Dsl без изобретения языка - это когда вы берёте подмножество существующего яп и даёте прикладниками его. Без потери выразительности можно было использовать и linq-синтаксис C#, перегрузив SelectMany и Select и компутейшны из F# и kotlin dsl, но вы написали своё. Я не увидел ни одного комментария вида "о, да точно, вот такого не хватало" в оригинальной статье, но вы продолжаете настаивать, что ваш язык лучше. На мой вкус он ничем не примечательный и никаких революций вы не произвели. Tool support вашего dsl хуже, чем у mainstream-языков. Вы утверждаете, что "он понятнее для не программистов", но это бездоказательно. Объясните, почему нельзя добиться тех же результатов используя вашу платформу и один из языков на выбор в качестве dsl: Kotlin, C#, F#, TS, Python, Ruby. Я могу изобразить аналогичный вашему код на каждом из этих языков. А копипастить по примеру и обезьяну можно научить.
Может поэтому пошёл такой бум на автоматизацию медицины?
Справедливо:)
Либо вы плохо знакомы с 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 был
Я по этому поводу согласен с @lair, что можно словить нежданчик. Может имело смысл сделать отдельную перегрузку для IList, чтобы такие вещи были более явными.
Пока вы не добавили предикат
Это терминологическая демагогия. Каким термином вы предлагаете кратко описывать ситуацию, когда метод работает с одним специализированным типом из иерархии, но не работает с другим?