Здравствуйте, Kolesiki, Вы писали:
K>]Я — проф.разработчик K> мой главный и единственный язык — C#. Он же и "язык мышления".
Противоречие detected.
K> Прыгать с языка на язык я мог себе позволить в бестолковом студенчестве, да и то требовалась "перестройка сознания". Сейчас, когда в "рабочем сознании" я "сишарплю", у меня просто нет возможности и желания ещё и продираться сквозь дебри мусора от второго языка: "А можно ли завести виртуальный статический метод?".
Возможности есть — желания нет.
K>Сейчас язык — один и я знаю практически все ответы на любой архитектурный вопрос. Ломать голову на два языка — увы, непозволительная для профессионала роскошь.
У меня в коробке с шуруповёртом лежат биты Pz, Ph, простые и с ограничителем для гипрока, обычные шлицевые, Torx-звёздочки, на внутренний и внешний шестигранник в ассортименте, конусное сверло, всякие шарошки... И это не говоря уж про угловую башку и несколько удлиннителей биты разного калибра. Потому что надо. Ходить с одной отвёрткой и быть "Senior Pz Screwdriver" — увы, непозволительная для профессионала роскошь.
K>"Изучать язык" — это не методичку лектору пересказать! Это долгий, глубокий процесс, изучение ньюансов, отличий от "ООП-классики", всякие сахарки и приколы.
Само собой. Но это не повод отказаться.
K>Если выбирать язык, то один и "пока смерть не разлучит вас".
Эти споры были актуальны у нас "во студенчестве". В итоге, изучив в универе Паскаль и Си, я вышел на первую работу по FoxPro, проведя перед этим несколько дней с книгой по языку. Интернета тогда ещё не было.
K>Да у меня самые "фичастые" WPF-ки (где много декларашек перелопачивается в C# код) канпеляются от силы секунд 5! Как так-то??
Значит, они маленькие. MVVM с бихейворами, конвертерами и прочей требухой в пять секунд уже не уложится.
K> И дело не в котлине — с жабой ровно та же тормозня.
Так Котлин — это перелицованная жаба и есть. Возможно, когда-то JetBrains смогут выделить это как самодостаточный язык, но пока что имеем что имеем.
K>Сюда же "организованная гиперпомойка исходников", из которой состоит ЛЮБОЙ проект для Ведроида. 8 каталогов для простейшего приложения? Серьёзно??
То ли дело у нас в шарпе, связка проектов — модели, сервисы, инфраструктура, везде папки для группировки по дочерним namespace...
K>Ведроид — это живой труп, могила здравого смысла — самое безобразное, что можно было придумать для простейших "мобилок".
На Windows Phone тоже не без приколов — пришлось хлебнуть полную лопату. А уж про свой опыт Симбиан — давайте не буду вспоминать
Здравствуйте, Kolesiki, Вы писали:
K>В условиях тотального оведроживания мобильного сегмента, у C#-программистов возникает естественное желание безнапряжно писать под Андроид.
Просто попробуйте писать под ведро на kotlin и вы на C# будете смотреть иначе.
Здравствуйте, kov_serg, Вы писали:
_>Просто попробуйте писать под ведро на kotlin и вы на C# будете смотреть иначе.
*смайлик горькой усмешки старика молодому поколению* Неужели ты думаешь, эта "светлая мысль" меня не посещала??
Беда в том, что все мы люди и поэтому имеем сразу целый ворох "почему НЕТ":
Я — проф.разработчик, мой главный и единственный язык — C#. Он же и "язык мышления". Прыгать с языка на язык я мог себе позволить в бестолковом студенчестве, да и то требовалась "перестройка сознания". Сейчас, когда в "рабочем сознании" я "сишарплю", у меня просто нет возможности и желания ещё и продираться сквозь дебри мусора от второго языка: "А можно ли завести виртуальный статический метод?". Сейчас язык — один и я знаю практически все ответы на любой архитектурный вопрос. Ломать голову на два языка — увы, непозволительная для профессионала роскошь.
"Изучать язык" — это не методичку лектору пересказать! Это долгий, глубокий процесс, изучение ньюансов, отличий от "ООП-классики", всякие сахарки и приколы. Если выбирать язык, то один и "пока смерть не разлучит вас". Но я не могу менять "рабочий язык"! Даже в качестве хобби. Потому что как и сказал в п.1, ты получишь груду мусора из 2 языков и постоянно будешь тупить даже при том, что отлично знал один из языков.
Но ситуация ещё хуже: язык — ничто без библиотек. И чтобы сносно даже открыть файл, придётся перелопатить СОТНИ классов, примеров, "типичных способов употребления", прежде чем ты напишешь программу, достойную профессионала. Кстати, в моём "покорении Ведроида" упущен момент с базовыми классами .NET — их крайне желательно было бы "портировать", чтобы от ведроида использовать только графические плюшки и сервисы.
Писать под вердроид, особенно после шикарной VS, практически не на чем! Удивительно, но факт — за 12 лет эти тюлени не создали ни одной удобной, быстрой, легковесной IDE! Даже IDEA при всех своих плюшках — ужасна, а компиляция примитивнейших сорсов занимает МИНУТЫ!! Вы встречали подобный идиотизм в .NET? Да у меня самые "фичастые" WPF-ки (где много декларашек перелопачивается в C# код) канпеляются от силы секунд 5! Как так-то?? И дело не в котлине — с жабой ровно та же тормозня. Извините, ТАКОЙ тормозилище выбешивает похуже перфокарт.
Сюда же "организованная гиперпомойка исходников", из которой состоит ЛЮБОЙ проект для Ведроида. 8 каталогов для простейшего приложения? Серьёзно?? А вот это ублюдство:
(это так ищутся и только потом используются контролы в коде) Это шутка такая штоле?
Откровенно, мне Котлин тоже нравится (причём даже после C#), но ублюдская компиляция и тухлые IDE — то болото, в которое ступаешь однажды и хочется поскорее оттуда убежать.
Ведроид — это живой труп, могила здравого смысла — самое безобразное, что можно было придумать для простейших "мобилок".
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Serginio1, Вы писали:
S>> А чем это лучше Linq? Там еще есть и IQuriable на Expression Tree
Q>Я вообще не про Linq, при чём здесь Linq? Это про синтаксис лямбд.
Ну синтаксис содран с TypeScript
в C# есть куча Func<T,...T64> и Action это по моему проще.
Единственно что проблемы с var и out параметрами приходится писать через delegate
Кстати в примерах нет лямбд с out и var параметрами
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Kolesiki, Вы писали:
K>Причём тут экран?? Неужели со всего поста непонятна главная задача: писать под ведроид, но на C#? Тут вообще никакой речи про совместимость. Просто считай ты вчера родился, а сегодня захотел написать ведроид-приложение, а в школе ты изучал C#.
И в этот момент ты узнаешь шокирующую новость: то, чему тебя научили в школе, не подходит, чтобы зарабатывать на кусок хлеба. Поэтому ты идешь работать официантом в макдональдс, а вечерами подучиваешь недостающие знания.
В условиях тотального оведроживания мобильного сегмента, у C#-программистов возникает естественное желание безнапряжно писать под Андроид. На сегодня всё, что предлагает M$ — это Xamarin, который на мой частный взгляд, "пятое колесо в телеге", причём не самого высокого качества. А учитывая, КАК это чудище работает в Ведроид-среде, закономерно хочется выкинуть архаичные "mono-CLRы" с "прокси" и выпускать "почти нативные" приложения, полностью и напрямую используя Ведроид-АПИ. Как мне видится один из вариантов "освоения Ведроида дотнетом":
Раз у нас есть Roslyn, мы можем с лёгкостью брюк, превращающихся в шорты, запилить вывод JVM-кода. Да, возможно некоторые плюшки CLR придётся поскипать (dynamics? Много ли они кому нужны?). Главное — мы можем выпускать приложения, "нативные для Жабы". Работа — не бей лежачего, уж куда проще запиливания отдельной CLR для Андроида! А далее как по смазке: создаём врапперы к Андроид-АПИ, которые будут "MSIL-библиотеками". Т.е. Студия будет с ними работать вполне прозрачно.
Следующий этап — "WPF на мобильный лад": делаем декларативную ГУЙню, которая 1:1 мэпится в контролы Ведроида (даже с теми же именами). Синтаксис будет XAML'овый. Опять же, невелика работа — сконвертировать теги в контролы мобилы и инициализировать свойства.
Сама разработка (поначалу) прекрасно будет идти на родной Вендюшечке, где мы собираем бинарные apk, заливаем по USB в ведроид и вуаля — аппликуха на C#/WPF, которая "как влитая" нативно работает в неуклюжем Ведроиде!
Касательно "мышедизайна", тут всё просто: на венде будут работать минимально-функциональные mock-контролы, имитирующие Ведроидные — так вы будете видеть все цвета, выравнивания и т.п. А в результирующий apk уже пойдут прямые обращения к Андроиду.
Напомню, это всё всего лишь инженерная идея, как можно было БЫ сделать это по-человечески. И конечно же, крайне приветствуются ваши мнения, которые вы конечно же медленно обдумаете, прежде чем публиковать — вопрос-то вполне технический и интересный. Итак, что вы думаете по поводу сей системы?
Здравствуйте, Je suis Mamut, Вы писали:
JSM>экран другой, устройство ввода другое, всё равно гуй рисовать заново
Причём тут экран?? Неужели со всего поста непонятна главная задача: писать под ведроид, но на C#? Тут вообще никакой речи про совместимость. Просто считай ты вчера родился, а сегодня захотел написать ведроид-приложение, а в школе ты изучал C#.
Спасибо! Но он платный, увы. Да и словоблуды они ещё те провёл на сайте 10 минут, пытаясь понять, что там "нативного". Боюсь, что вывеска как всегда круче товара.
Так или иначе, крайне сомнительно, что они приблизились к моей идее.
Здравствуйте, Kolesiki, Вы писали:
Pzz>>Практический интерес представляет другая задача: писать под андроид и макакос, чтобы из одного кода под обе системы получалось
K>Интерес как раз сугубо мечтательско-теоретический. На практике "один код для двух платформ" — маниловщина.
Здравствуйте, Kolesiki, Вы писали:
K>Причём тут экран?? Неужели со всего поста непонятна главная задача: писать под ведроид, но на C#? Тут вообще никакой речи про совместимость. Просто считай ты вчера родился, а сегодня захотел написать ведроид-приложение, а в школе ты изучал C#.
Ява после Шарпа осваевается с пол пинга. Имел недавно опыт. Хватило пары недель в процессе работы над проектом. Но до этого как раз на Кзамарине где-то пол года под Ведроид по-программировал.
У Кзамарина, кстати, есть неоспаримые преимущества, когда речь идет о разработке ГУЯ. Все же MVVM рулит. Андроид сильно отстает в этом плане. Плюс у Кзамарина переносимость гуя на iOs.
К сожалению, АПИ телефонов очень разные и Кзамарин тут ничего не может предложить в принципе. Но если приложение — это в основном ГУЙ, то Кзамарин рулит и идея топикостартера не такая уж глупая, потому как в Кзамарие действительно самый гнилой момент — это его VM.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kolesiki, Вы писали:
K>Следующий этап — "WPF на мобильный лад": делаем декларативную ГУЙню, которая 1:1 мэпится в контролы Ведроида (даже с теми же именами). Синтаксис будет XAML'овый. Опять же, невелика работа — сконвертировать теги в контролы мобилы и инициализировать свойства.
Только в этом и есть смысл. Кзамарин зря использует промежеточную VM. Действительно было бы лучше не ставить свою ВМ, а конвертить код в Яву и андройдные примитивы. Но ты недооцениваешь сложности задачи. Задача не простая. Но решаемая.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kov_serg, Вы писали:
_>Просто попробуйте писать под ведро на kotlin и вы на C# будете смотреть иначе.
Не будете. В Кзамарине важен не даже не сам Шарп, хотя и он на сегодня более продвинуты чем Котлин, а MVVM. А этого в Ведройде нет в принципе. Там довольно убогий АПИ в базе.
Ну, и кайф Кзамарина в том, что он позволяет писать ГУЙ не только для Ведройда, но и для iOs. А это дорогого стоит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
S> Ну синтаксис содран с TypeScript
Во-первых, сдирать с других я зыков это не то что зазорно; это в принципе лежит в основе проектирования Kotlin. У Андрея Бреслава — главного архитектора языка — есть даже лекция на эту тему: «На плечах гигантов: языки, у которых учился Kotlin». Он её много раз читал на разных конференциях.
S> Ну синтаксис содран с TypeScript
Во-вторых — а можно пруфы? Я не знаю TypeScript, но не могу нагуглить про обсуждаемые trailing lambdas и single parameter lambdas.
S> в C# есть куча Func<T,...T64> и Action это по моему проще.
Причём здесь... Создаётся впечатление, что ты совсем не понял, о чём шла речь. Ты точно читаешь ответы на свои вопросы? Или это для тебя просто low-effort-чатик с целью потратить время собеседников?
val numbers = mutableListOf("one", "two", "three")
val firstAndLast = with(numbers) {
"The first element is ${first()}," +
" the last element is ${last()}"
}
Здесь «with(numbers) {...}» с протаскиванием контекста в this (чтоб писать first() вместо numbers.first()) выглядит как специальный синтаксис с блоком инструкций {...}; похожий есть и в других языках. Но в Kotlin это обычная функция, вызываемая с trailing-лямбдой.
Если не ошибаюсь, то всяческих конвертеров с c# на ява на уровне байт-кода не мало. Т.е. это не проблема.
K>Следующий этап — "WPF на мобильный лад": делаем декларативную ГУЙню, которая 1:1 мэпится в контролы Ведроида (даже с теми же именами). Синтаксис будет XAML'овый. Опять же, невелика работа — сконвертировать теги в контролы мобилы и инициализировать свойства.
А вот тут затык. Если надо написать консольную утилиту или процесс, то можно код конвертировать на уровне байт-кода.
А вот на счет UI и 'которая 1:1 мэпится в контролы Ведроида' самая сложность и есть, кмк.
Т.е. нужен будет транслятор с XAML на соотв. язык разметки ui ведра или напрямую в ява код. Причем важна
совместимость по вызовам всяческих событий обработки и т.п. Т.е. это весьма нетривиальная задача.
Встает другой вопрос -- в чем проблема, зная c# перейти на яву, если очень надо? При уверенном знании языка
вкатка будет от силы пару месяцев.
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, Kolesiki, Вы писали:
K>>В условиях тотального оведроживания мобильного сегмента, у C#-программистов возникает естественное желание безнапряжно писать под Андроид. _>Просто попробуйте писать под ведро на kotlin и вы на C# будете смотреть иначе.
Кстати а, что в котлине интереснее по сравнению с C#9 ?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Кстати а, что в котлине интереснее по сравнению с C#9 ?
Там есть много хороших фич, конечно, и я назову не главные. Но меня прёт от синтаксиса лямбд для некоторых частых частных случаев.
it: implicit name of a single parameter
It's very common that a lambda expression has only one parameter.
If the compiler can figure the signature out itself, it is allowed not to declare the only parameter and omit ->. The parameter will be implicitly declared under the name it:
ints.filter { it > 0 } // this literal is of type '(it: Int) -> Boolean'
Passing trailing lambdas
In Kotlin, there is a convention: if the last parameter of a function is a function, then a lambda expression passed as the corresponding argument can be placed outside the parentheses:
val product = items.fold(1) { acc, e -> acc * e }
Such syntax is also known as trailing lambda.
If the lambda is the only argument to that call, the parentheses can be omitted entirely:
Здравствуйте, Kolesiki, Вы писали:
K> В условиях тотального оведроживания мобильного сегмента, у C#-программистов возникает естественное желание безнапряжно писать под Андроид. На сегодня всё, что предлагает M$ — это Xamarin, который на мой частный взгляд, "пятое колесо в телеге", причём не самого высокого качества. А учитывая, КАК это чудище работает в Ведроид-среде, закономерно хочется выкинуть архаичные "mono-CLRы" с "прокси" и выпускать "почти нативные" приложения, полностью и напрямую используя Ведроид-АПИ.
Здравствуйте, Kolesiki, Вы писали:
K> R>Есть вот такой зверь https://www.elementscompiler.com
K> Спасибо! Но он платный, увы. Да и словоблуды они ещё те провёл на сайте 10 минут, пытаясь понять, что там "нативного".
Там под нативностью понимается нативность по отношению к платформе https://docs.elementscompiler.com/Platforms/. Пишешь под дотнет, на выходе будут сборки, пишешь под жабу, будут джары с байткодом, пишешь под win32 будет бинарник и т.п. Есть небольшой кроссплатформенный слой, но в основном писать придется используя api платформы (т.е. никаких дотнет типов, например, на андроиде не будет).
JSM>>все приседания нужны когда под обе мобильные платформы пишешь — чтобы два раза не писать
Pzz>Практический интерес представляет другая задача: писать под андроид и макакос, чтобы из одного кода под обе системы получалось
ну я вроде как ровно это и имел ввиду
не быть мне оратором, не быть
Здравствуйте, Je suis Mamut, Вы писали:
JSM>>>все приседания нужны когда под обе мобильные платформы пишешь — чтобы два раза не писать
Pzz>>Практический интерес представляет другая задача: писать под андроид и макакос, чтобы из одного кода под обе системы получалось
JSM>ну я вроде как ровно это и имел ввиду JSM>не быть мне оратором, не быть
Ну тут смущает то, что говорится это в контексте C#, а мобильная венда хоть и померла, но память об ней еще жива.
Здравствуйте, Pzz, Вы писали:
Pzz>Практический интерес представляет другая задача: писать под андроид и макакос, чтобы из одного кода под обе системы получалось
Здравствуйте, Sharov, Вы писали:
Pzz>>Практический интерес представляет другая задача: писать под андроид и макакос, чтобы из одного кода под обе системы получалось
S>Кроме плюсов и всяческих js так кто-то умеет?
Ну, этого можно достичь разными путями.
Можно, например, притащить с собой веб-броузер, и сделать все на htpm+js+css. Получившееся поделие будет весить мегабайт 50, но кого этим сейчас смутишь?
Можно вспомнить про то, что обе платформы поддерживают нативные бинарники. На андроиде, правда, так не принято, но и не запрещено. Тогда проблема будет в кросс-платформенной графике. Можно притащить с собой какой-нибудь Qt, весить, правда, будет не сильно меньше, чем если притащить с собой броузер.
Ну и наконец, можно рассмотреть языки, которые могут быть перекомпилированы в Java/ObjC (или чего там сейчас модно на макакосе). Проблему с кросс-платформенной графикой, правда, это не решит.
Можно ограничиться графикой на уровне OpenGL, она, похоже, довольно одинаковая на обеих платформах. Тогда получится использовать нативные бинарники, и не притаскивать с собой Qt. Выглядеть, правда, будет ужасно, OpenGL плохо подходит для рисования формочек. Так можно даже на Go писать
Но в общем, готового out of box и без геморроя решения, похоже, нет. Присутствующие на форуме шароварщики могут при желании этим заняться.
Здравствуйте, rudzuk, Вы писали:
R>Там под нативностью понимается нативность по отношению к платформе https://docs.elementscompiler.com/Platforms/. Пишешь под дотнет, на выходе будут сборки
ХА! Так это и есть "маркетинговая нативность"! Реальная нативность в контексте Ведроида — прога для JVM.
Здравствуйте, Pzz, Вы писали:
Pzz>Практический интерес представляет другая задача: писать под андроид и макакос, чтобы из одного кода под обе системы получалось
Интерес как раз сугубо мечтательско-теоретический. На практике "один код для двух платформ" — маниловщина.
Здравствуйте, Pzz, Вы писали:
Pzz>Но в общем, готового out of box и без геморроя решения, похоже, нет. Присутствующие на форуме шароварщики могут при желании этим заняться.
Здравствуйте, Quadri, Вы писали:
Q>Кстати, вот недавно объявили кроссплатформенную (пока десктоп и андроид) UI библиотеки: Jetpack Compose Desktop на Kotlin подробнее https://habr.com/ru/post/527586/
Ну интереснее, конечно, андроид и иос. Полагаю граждане, занимающиеся программами для мобильных устройств, изрядно подзадолбались параллельно две версии таких програм вести.
Андроид/дектоп менее интересно. Под дектоп, все же, пользовательский интерфейс сильно по-другому строится, чем под телефон.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Serginio1, Вы писали:
S>>Кстати а, что в котлине интереснее по сравнению с C#9 ?
Q>Там есть много хороших фич, конечно, и я назову не главные. Но меня прёт от синтаксиса лямбд для некоторых частых частных случаев.
Q>
Q>it: implicit name of a single parameter
Q>It's very common that a lambda expression has only one parameter.
Q>If the compiler can figure the signature out itself, it is allowed not to declare the only parameter and omit ->. The parameter will be implicitly declared under the name it:
Q>
Q>ints.filter { it > 0 } // this literal is of type '(it: Int) -> Boolean'
Q>
Q>Passing trailing lambdas
Q>In Kotlin, there is a convention: if the last parameter of a function is a function, then a lambda expression passed as the corresponding argument can be placed outside the parentheses:
Q>
Q>val product = items.fold(1) { acc, e -> acc * e }
Q>
Q>Such syntax is also known as trailing lambda.
Q>If the lambda is the only argument to that call, the parentheses can be omitted entirely:
Q>
Здравствуйте, Pzz, Вы писали:
Pzz>Можно притащить с собой какой-нибудь Qt, весить, правда, будет не сильно меньше, чем если притащить с собой броузер.
Насколько я понимаю, это потому, что Qt поддерживает все в одном флаконе, и никак иначе. Его разработчики принципиально не делают так, чтобы можно было подключать только необходимую функциональность, без излишеств? Или делают, но всем лень выбирать, и суют в дистрибутивы стандартные полнофункциональные оболочки?
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>Можно притащить с собой какой-нибудь Qt, весить, правда, будет не сильно меньше, чем если притащить с собой броузер.
ЕМ>Насколько я понимаю, это потому, что Qt поддерживает все в одном флаконе, и никак иначе. Его разработчики принципиально не делают так, чтобы можно было подключать только необходимую функциональность, без излишеств? Или делают, но всем лень выбирать, и суют в дистрибутивы стандартные полнофункциональные оболочки?
С мобильным Qt я дела не имел, а дектопный вендовый/линуховый разрезан на какое-то количество DLL-ек, так что теоретически можно притаскивать только нужные (или слинковаться статически, если более традиционных форм секса в жизни не хватает).
Но там все на все завязано, так что если даже лишнего (не используемого) не тащить, все равно много чего притащится.
Fire and Water are our state of the art development environments for programmers using the Elements compiler on the Mac and on Windows, respectively.
— https://docs.elementscompiler.com/Fire/
Чуваки пилят компилятор своего диалекта C# и — внимание — свои IDE. State of the art, ага.
Здравствуйте, Qbit86, Вы писали:
Q> Чуваки пилят компилятор своего диалекта C#
На счет собственного диалекта:
The RemObjects C# compiler will evolve as the official C# language evolves, but our goal is not to drive the C# language forward (and diverge from the standard) ourselves, but rather to provide a compiler and language for .NET, Cocoa and Java that will feel like "true C#" to everyone familiar with the language.
That said, RemObjects C# does adds a few features to the standard C# language to make it fit better on all the platforms it supports. These are covered under Language Extensions.
Не такой уж он и собственный. Platform specific расширениями пользоваться никто не заставляет.
Q> и — внимание — свои IDE. State of the art, ага.
Здравствуйте, Qbit86, Вы писали:
Q> R>Не такой уж он и собственный.
Q> Как выглядит работа со структурами в таком C# на JVM (Dalvik, ART), которая значимые типы не поддерживает AFAIK?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ладно, "ксерокс" еще можно было простить за отсутствием словарей, но "ксеон" до сих пор режет глаз и слух, а теперь еще и "кзамарин"...
Привыкай. Буквы Экс в нашем языке нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Serginio1, Вы писали:
Q>Там есть много хороших фич, конечно, и я назову не главные. Но меня прёт от синтаксиса лямбд для некоторых частых частных случаев.
Q>
Q>Passing trailing lambdas
Q>In Kotlin, there is a convention: if the last parameter of a function is a function, then a lambda expression passed as the corresponding argument can be placed outside the parentheses:
Q>
Q>val product = items.fold(1) { acc, e -> acc * e }
Q>
Q>Such syntax is also known as trailing lambda.
Q>If the lambda is the only argument to that call, the parentheses can be omitted entirely:
Q>
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Serginio1, Вы писали:
S>> Ну синтаксис содран с TypeScript
Q>Во-первых, сдирать с других я зыков это не то что зазорно; это в принципе лежит в основе проектирования Kotlin. У Андрея Бреслава — главного архитектора языка — есть даже лекция на эту тему: «На плечах гигантов: языки, у которых учился Kotlin». Он её много раз читал на разных конференциях.
S>> Ну синтаксис содран с TypeScript
Q>Во-вторых — а можно пруфы? Я не знаю TypeScript, но не могу нагуглить про обсуждаемые trailing lambdas и single parameter lambdas.
Спутал с хаскелем
В TypeScript
(x: number, y: number) => number
S>> в C# есть куча Func<T,...T64> и Action это по моему проще.
Q>Причём здесь... Создаётся впечатление, что ты совсем не понял, о чём шла речь. Ты точно читаешь ответы на свои вопросы? Или это для тебя просто low-effort-чатик с целью потратить время собеседников?
Да прошу прощения. Каюсь
Но в чем профит?
val product = items.fold(1) { acc, e -> acc * e }
на шарпе
var product = items.fold(1,(acc, e) => acc * e)
ints.filter { it > 0 }
на шарпе
ints.filter ( it=> it > 0 )
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, sergeya, Вы писали:
S>>Это вызов метода с тремя параметрами, последний из которых — лямбда. Где логика, где смысл?
Q>Как минимум, это удобно при вложенности таких лямбд. Например, при определении «DSL» через билдеры (частый паттерн в Kotlin): https://kotlinlang.org/docs/reference/type-safe-builders.html
Имхо такая неоднозначность в синтаксисе — это слишком большая цена за возожность писать одинарные скобки вместо двойных "{ ... }" vs "({ ... })".
И плохо, что рефакторинг в Android Studio настаивает на использовании такого синтаксиса везде без разбору.
p.s. А пример c dsl-ем интересный, не знал о таком приемчике. Спасибо )