Официальная документация компании разработчика языка подойдет
Не уверен.
Тут ситуация в чем — просто документации мало.
т.е. хорошо что оно есть, но это только начало.
Эта документация и стандарт языка воплощены в виде автоматических тестов?
Есть процесс сертификации сторонних реализаций котлина на предмет совместимости? Если вы обеспечите процесс сертификации под каждую версию, то и вопросы обратной совместимости будут выявляться на раз-два. Если нет — то что — остается «верить на слово»?
Если вспомнить историю, то (фактически) отсутствие процесса сертификации привело к тому, что, например, разные версии руби под разные платформы и среды не полностью совместимы друг с другом. А про разнообразие сишных не совместимых друг с другом компиляторов — помолчу — это «притча во языцах».
Если противопоставить джаву этому хаосу, то у джавы, например, есть процесс сертификации компилятора/джавамашины.
Вы же, по крайней мере пока, предлагаете «наслово поверить документации» и обещаниям. Но, повторюсь, чем они подтверждены? Заверениями что внутренние процессы компании производителя это обеспечивают? ага… 3 раза вам поверили.
Если вы предлагаете переходить на другой язык, причем _полностью_, надо нечто большее — например механизм обеспечения гарантии того, что кто-то другой может производить 100%-совместимые компиляторы. Почему это важно? Сегодня JetBrains есть, а завтра обанкротились. А нам что делать с туевой массой кода на хйповом котлине? Где вот скажем Borland со своим Delphi? «а нигде», образно говоря. В былые времена все и всё на дельфятине писали.… огогооо!… С джавой же ситуация кардинально другая — джаву, извините, не только Oracle поддерживает. Тут и сообщество, и IBM… т.е джаве есть хоть какая-то уверенность в завтрашнем дне. А в котлине?
И вот к JetBrains — вопрос — как они собираются обеспечивать долгую жизнь котлину? обещаниями и документацией? нуну…
SUN, имхо, в свое время понимали эту проблему, и сделали спеки полными и отрытыми. В том числе был создан, в конце концов и процесс сертификации сторонних джава-машин. И это, в том числе, обеспечило распространение джавы, «буквально везде», а в купе с обратной совместимостью — позволило стать промышленным стандартом. После них, по моим сведениям, никто другой такой подвиг не повторил.
И так… процесс сертификации компиляторов котлин от других производителей.
Он есть? Потому что это один из немногих, действенных способов обеспечить гарантии совместимости. Если у вас есть другие мысли о том как это гарантировать кроме как «поверить на слово производителю» — предлагайте.
Я вот правда не знаю что вам ответить. Это вопрос из разряда «Ты перестал бить жену по утрам?». Так как котлин компилируется в байткод исполняемый JVM, как и Java, то и бинарная совместимость будет как у Java. Ну как-то так.
Аналогия интересная, но не совсем.
Тут скорее вопрос о том, как производитель обеспечит совместимость с новымми версиями джавы, и я, признаться, надеялся, что вы скажете, что либо типа «они используют те возможности джава6 которые остались неизменными на протяжении 6-7-8-9 версий… ». Ну в варианте, когда вы используете Java6 и последнюю версию компилятора котлин конечно…
Но ничего подобного не прозвучало. Вы предлагаете, повторюсь, довериться разработчикам?
Если посмотреть в спеки различий между java6 и java7 то в принципе становится понятно, почему, некоторые проекты имеют проблемы с поддержкой новых версий джавы. Вот скажем забавный пример — aNimble — ныне мертвое продолжение другого ныне мертвого проекта «Open Source Requirements Management Tool». написано под GRAILS… и вот факт такой: то что лежит на sourceforge.net — байтвод, джарники — это всё не работает под Java7. Только под Java6.
Почему так? не знаю… то ли они рефлекшен пользуют для доступа к приватным фунциям (вам разве сразу не говорили что так делать не надо?) или их логика работы завязана на порядок выдачи функций класса в рефлекшен-функциях? (а у вас в доках разве гарантирован порядок выдачи элементов?)…
Но на своей шкуре проверил — оно работает только под java 6.
И вот глядя на ЭТО, у меня и возникает вопрос — как именно производитель котлина собирается обеспечивать совместимость с Java 6|7|8|9|10? Какие методы обеспечения совместимости или хотя бы методы выявления несовместимостей… а вы мне про бинарную совместимость байткода. Ну не про это же речь.
Вот с джава все понятно — есть сертификация сторонних компиляторов и систем/сред/программ… а что с котлином и JetBrains?
Вообще, авторы в каждом докладе, где рассматриваются эти вопросы, клянутся, что обратная совместимость для них наиважнейший фактор при развитии языка. Со слов Андрея Бреслава, «пока люди используют Java 6, Kotlin будет с ней совместим» (почти дословно)
Я не про совместимость с Java 6. Я про совместимость версий языка — старых версий с новыми.
Вот скажем, как авторы котлина собираются обеспечить гарантии того, что когда выйдет версия 1.3, вам не потребуется перекраивать код уже написанный на котлине 1.2?
Ну и… «клятвы» — это хорошо. Но «где ваши доказательства»?
Есть ли для котлина полная спецификация языка с детальным описанием поведения каждой конструкции, как это есть для Java и Java-машины?
Вот в джаве описанные вещи обеспечиваются именно детальной спекой, с последовательным включением в эту спеку всех оговорок и исключений, связанных с поведением старых версий джавы на новой машине и в окружении новых фич языка.
А что с котлином?
У меня работает
Ну, вы же понимаете, что это не доказательно? Хелло-ворды, вот скажем, всегда везде работают. Но мы же не про них говорим.
Простите, но я снова задам «эти 2 вопроса».
Извините, еще раз, за язвительность, но:
1) означает ли «100%-я совместимость» с java, что байткод, собранный компилятором котлина на 6й джава машине будет работать на 7й без пересборки? (замените цифры 6 и 7 на актуальные или вами любимые по возрастанию). A если будет, то будет ли он работать точно так же?
2) кто гарантирует что новые версии котлина будут 100% обратно совместимы со своими предшественниками? будет поддерживаться несколько веток котлина как это (все еще?) происходит с питоном или авторы котлина просто откажутся от поддержки старых версий, написав письмо вида «извините, мы знаем, что все еще не можете перейти на новую версию из-за проблем с обратной совместимостью в языке, и большого объема ваших проектов, но (нам пофиг) мы снимаем старую версию с поддержки», как это было с руби?
Скептик внутри меня говорит, что есть серьезное подозрение, что с точки зрения идеологов котлина, ни первое ни второе решать корректно «совершенно не обязательно», потому что «это всё это уже 100 раз видели» на примере других «байткод-совместимых языков», разных «убийц джавы» и многих других хороших и не очень языков.
А если не ответить правильно на эти 2 вопроса, это означает что это никакого большого промышленного будущего у этого языка нет, и говорить о котлине как о заменителе джавы нельзя. равно как и писать большие, долгоживущие проекты тоже «опасно» (банально есть риски отхватить тружноотлаживаемые проблемы при смене версий). Сначала — удобный синтаксис, приятные фичи… а потом…
Хорошая статья. Но разве не лучше указать в заголовке область?
скажем «Задачи с собеседований (web front-end)».
А то я уже приготовился читать TOP10-подборку маразматическо-смешных вопросов, которыми оные HR от излишнего рвения любят иногда грузить подателей резюме… а тут банальная js-ина)
— Кстати, про css-центрирование по горизонтали и вертикали разве ни разу не спросили?
А я бы спросил. Особенно после того, как полез я тут выяснять как это делать… и отгреб на 5 разных сайтах 25 разных вариантов, из которых у меня не получилось запустить ни один. Я не очень силен в css, да. А получилось, кстати, запустить код из комментариев.
Вот вы бы как сделали центрирование в ячейке (div) который преобразует внутреннюю модель таблицы в визуальное представление? В свойствах ячейки таблицы (в модели) есть свойства valign и halign со значениями 'start', 'middle' и 'end'. Размеры содержимого ячейки и внешнее обрамление (за границами вашего div) могут быть любые. Надо что бы ваше позиционирование работало всегда.
Вы меня, конечно, извините… понимаю, что, наверное, «это просто по времени совпало с внедрением чего-то там большого» у вас…
… но вот генерировать текст смс с суммой операции в момент совершения операции, а баланс брать на момент отправки смс — это, возможно, самое глупое что можно придумать в смс-информировании ))
потому что пока вы там «прокачатете смс по очередям» — я сделаю ещё пяток операций и в итоге мне уже около полугода периодически приходят замечательные сообщения типа «поступление 20 000.00 рублей, баланс 10.00 рублей» ))
поправьте сначала это, а уже потом хвалитесь «большими данными». ну серьезно. <_<
И все бы ничего, но список патентов — не оглашается.
А в тех случаях когда список всплывает — оказывается, что эти патенты — prior-art в лучшем случае.
Как много всего намешано у автора… слишком много и всё в кучу.
Прямо таки слышится вопль «оскорбленного глупыми HR-ами» «простого it-работника», который «просто работает свою работу», и которого обижает сравнение с «увлеченными своим делом», вплоть до того, что он сравнивает их с «роботами напивающимися в стельку каждую пятницу»? <_<
А по мне так, что «просто работать свою работу» по часам — это как раз и есть «быть роботом». Но не суть) такие простые работяги тоже очень нужны. На них очень многое держится.
… а мне одному показалось, что HR-ы, которые «обидели» автора — тоже «просто работники, у которых есть работа, и они её работают, с часовым перерывом на обед», не очень вдаваясь глубоко в детали?
Они витают в своих мифах про «увлеченных разработчиков»… — впрочем, равно как и автор, который думает, что на рабочем месте разработчика ПО, его будут ценить за писательство/художества/увлечения (и, конечно же, а как иначе выразить это уважение — поднимут из-за этого его з/п ?!)
Получается, он, «простой работник», не доволен тем как поступают «другие просто работники» (но уже в роли 'HR') — и у которых (как и у автора текста) нет желания погружаться в суть вопроса чуть более чем на 8 часов?
И, вот вопрос: как предполагается погрузиться в суть какого-либо серьезного вопроса, если не «переспать с проблемой», если постоянно переключать мозг на десяток других задач — то там у парня «собачий бизнес», то походы, то искусство, то ещё десяток других увлечений… когда его мозг успеет настроиться на решение?
В случае серьезных задач — за 8 часов, вы можете едва улучшить то, о чем вы думали вчера вечером, стоя в душе, и то, над чем ваш мозг думал во сне. И увы, именно такой ценой люди двигают/решают сложные задачи. И да, таких единицы. Для них, решение таких задачек — это их «хобби», они не переключаются на «собачий бизнес» выходя с работы. И да, в такой сложной области как IT — именно такие люди становятся «легендами» и «звездами». И, согласитесь, понятно, что за ними охотятся любые HR.
Но крайне необходимо понимать, что «то, что делают звезды» — не отменяет ценность и важность труда тех, кто рутинно оттачивает и реализует ключевые решения «увлеченных». Тут нет лучших и худших. Тут есть 2 разных, дополняющих друг друга стиля.
Но, почему, как мне показалось, этого не понимают не только упомянутые HR-ры, но и сам автор?
От жонглирования синонимами ничего не меняется. Если для меня нет способа найти разницу между двумя представлениями, значит этой разницы нет. Бритва Оккама во все поля.
Получается, что «по вашей версии бритвы оккама» — оптимизирующий компилятор ничего не меняет? но по факту же он «что то» меняет — программа начинает работать быстрее, меньше ресурсов используется.
Так какую логику он меняет — можете описать? не уходите от ответа.
Во-вторых, «волшебным образом» он это делает потому, что это по сути и есть callback, о чем вам сто раз сказали. Но вы, видимо, знаете, как работает await, лучше, чем официальная документация и целая куча специалистов и экспертов.
вот как раз в документации то, ничего про callback не сказано.
Более того — там несется некая ахинея про код, выполняющийся вне основного потока, но без потока. Я согласен что возможно, async таск выполняется вне потока вашей программы, а в неком «сервисном потоке», который предоставляется .net-средой -исполнения. Но если у вас есть вычисления внутри async функции, они будут выполняться внутри потока.
А в документации которую вы показали рассказывается о некой «магии», и ни слова о том, как это действительно проиходит. Потому вы или покажите офф. документацию где явно сказано, что там действительно последующая часть кода выносится в call-back-функцию, или признайте что вы «не совсем правы». Потому что повторюсь — в документации рассказывается о неких «contonuation» — а что это — нигде не написано.
Более — того. По большому счету не важно, что там внутри. Считаете что там создается асинхронный байткод — ок, я допускаю, я не против. Я против того, что бы на основании того, _во_что_ превращается await в машинном коде, классифиировать исходный код.
Await позволяет вам создавать код в синхронном стиле, который при компиляции создает асинхронный. Да, он добавляет в эту синхронность особые точки в которых поток может заняться другими задачами пока выполняется код вызванный через await. Да, такое особое свойство. Но код последователен, синхронен, событий и обработчиков в нем не объявлено. Значит это синхронный код.
А то что вы считаете что при синхронности должен «блокироваться поток» — это следствие того, что вы привязываете определение к конкретной реализации.
бритва оккама, говорите? если код построен по логике последовательного выполнения операций, синхронного, выглядит как синхронный, выполняется как синхронный. подчинятся логике синхронного — значит код синхронный.
Исходный код. но не байт код, который получаем в итоге компиляции.
не верно, потому что await не регистриурет никаких действий, и его поведение, на уровне исполнния последовательности строчек кода, ничем не отличается от работы семафора.
да, await волшебным образом не блокирует текущий поток, но это иные свойства, не связанные event-driven стилем разработки.
Во-первых, принципиальное отличие await от семафора — отсутствие блокировки.
давайте ещё раз)))
то что await, приводит к тому, что перебор операций исходного кода в данной точке приостанавливается (но поток не блокируется) — это хорошее свойство но с точки зрения поведения, эта логики кода, к понятию «асинхронность» он имеет отношение косвенное, связанное только с тем как оно реализовано.
Повторюсь — как вы будете классифицировать этот код, если он будет собран компилятором, который разнесет ваш код на 3 Runnable (до await, сам await, после await ), сложит их в очередь, и поставит на выполнение для некого планировщика? плаировщик будет брать на выполнение следующий раннабл только тогда, когда выполнится предыдущий.
первый и последний runnable он выполнит в gui потоке, сам await — в сервисном/фоновом.
Поведение будет точно таким-же.
«GUI-Поток» не блокируется, операции выполняются строго в нужном порядке, ждут друг друга без блокировки gui потока.
Классификация исходного кода изменится или нет? можете ответить на этот вопрос?
И есть, например, такая штука, как DMA, которой программно ставится задание что-то где-то переместить в памяти, и она потом это делает сама независимо от процессора, который в это время может делать что угодно другое.
DMA — это не выполнение вычислений описанных у вас в async функции.
Когда у вас вычисления внутри вызываемой через await функции — они выполняется внутри какого-то потока.
и выполняемое операционкой действия глубоко внутри — тоже формально прикреплены к какому-либо потоку. то не имеет отнощения к мифу о внепоточности кода внутри await
Значит все-таки врут. Как и мозилла, и куча других языков с аналогичным функционалом. в документации мозилла и в документации майкрософт одинакового только слово async.
Просто заговор какой-то
мозилла, в отличии от сишарпа, возвращает промис, в который вы подставляете функцию-обработчик, которая должны быть вызвана.
это построение асинхронного кода. в отличии от «не-явных преобразований в c#».
То есть асинхронность это что-то с коллбеками? :) Никогда не встречал такого определения. Наверное, все же бывает и по-другому.
асинхронность, это event-driven стиль построения системы. коллбеки — это наиболее частый способ указания на функцию обработчик.
у вас нет в коде событий и функции обработчика событий? значит ваш код — ни разу ни асинхронный, потому что он построен не по асинхронной логике.
то что появляется в результате неявных преобразований в байткоде при компиляции — дело совершенно третье (там действительно может быть полный аналог мозиловского асинка, но может и нет), и это попадает под тему замены логики работы при компиляции.
а то, что вы считаете что есть как-то по другому, так это итог замены понятий и путаницы в терминологии авторов сишарпа, и несоответствия этих теринов, тем, которые используют все остальные.
асинхронность это и есть про «я не могу дать результат сейчас, подожди, когда будет готово, и зарегистрируй действие, которое должно в этот момент произойти».
верно
await это как раз про это.
не верно, потому что await не регистриурет никаких действий, и его поведение, на уровне исполнния последовательности строчек кода, ничем не отличается от работы семафора.
да, await волшебным образом не блокирует текущий поток, но это иные свойства, не связанные event-driven стилем разработки.
Этим тайным знанием обладают все. Если вы вдруг все же не читали ссылку, которую я давал, то пожалуйста, и там на пальцах объясняется, почему асинхронность возможна с одним-единственным потоком, как действия могут выполняться без потока вообще, ну и прочие веселые темы.
асинхронность возможна с одним потоком, да.
действия выполняющиеся вне какого-либо потока — нонсенс, противоречит основам работы операционной системы. это базис. код всегда выполняется в каком либо потоке. сисемном, фоновом, еще каком. но если процессор исполняет код, значит какойто поток есть. могут быть действия или вычисления без потоков, но тогда не на процессоре. у нас наши коллбеки выполняются
или у вас есть ссылка на теорию операционных систем или ещё что что? бложики «разных специалистов» — это конечно хорошо, но подмена понятий — это уже плохо.
еще раз повторюсь: то, что await (вероятно) приводит к асинхронному байткоду — это результат компиляции. я могу вам постороить компилятор, который будет преобразовывать код в набор runnable (скажем до await и после) и выполнять эти раннаблы в пуле потоков, итоговое поведение будет точно точно таким же — это не будет блокировать ваш гуи поток, все что после await будет выполняться строго после завершния того раннабла, в который я засуну сам await, но это ни разу не будет асинхронный или синхронный байткод. это нечто иное.
Сохранения логики означает что используя средства языка я не смогу увидеть разницы между результатом работы скомпилированной программы от той, которая выполняется на процессоре, где этот язык является нативным. Это очевидное определение.
это сохранение поведения, а не логики работы.
да, поведение не будет противоресить той логике которую вы заложити в исходный код, но не факт что логика работы, структра кода будет такими же.
вот вам пример одинакового поведения, но разной логики: если насекомые используют магнитные поля что бы находить север, а птицы ориентируются по полярной звезде, и при этом в пасмурную погоду они не летают «потому что стремно» — разныцы вы в их поведении не увидите.
так и компилятор. он сделает такие реобразования, о которых вы и не помыслите, но поведение останется таким же.
Разной логики там быть не может, потому что одно является отображением другого
А вот какая логика будет использована на этом низком уровне — на уровне машинного кода или байткода — это уже его личное дело, покуда он остается в границах ожидаемого поведения, описанного языком высокого уровня.
Если в терминах маш. команд или байт кода цикл является джампом на лейбл начала цикла, логика цикла от этого не меняется
После «разворачивания циклов» у вас циклов как таковых не будет в байткоде, и не будет у вас ни джампов ни лейблов. Будет простой линейный код.
О какой «одинаковой логике» вы говорите? В сорсах у вас цикл и условия, а в байткоде — линейный поток вычислений без джампов и условий. это сохранение логики? О сохраннии какой именно логики вы говорите? не позорьтесь)))
или классифицируйте в терминах вашей вселенной, что именно делает с кодом оптимизирующий компилятор, и какую логику (или что именно?!) он меняет?
документация майкрософт… это очень скользкая штука. двусмысленнее этого только рекламные объявления.
в указанной вами статье от асинхронности только название, самопровозглашение «про асинхронность», да схожая с асинхронностью идея «отложенного задания» которая фактически описывается под видом «асинхронности».
прочитайте внимательно содержимое, ищите признаки описывающие асинхронность, и судите не по заголовку а по содержимому…
например там нет ни слова про коллбеки, или событийность, нет ни слова про асинхронный запуск (коим можно конечно классифицировать запучк процедуры в параллеьном потоке, но в асинк… типа же нет потоков(?)...)
там есть некая «регистрация продолжения (»continuation") про которыую никто не знает что это именно аткое.
судя по _содержимому_ это не асинхронность. это нечто другое. это некий механизм отложенных заданий, с принудительным вызовом задания к исполнению в момент await, с отсутствием блокировок, который обладает некими плюсами которыми обычно обладает асинхронный код, но обладающий логикой и стилем синхронного.
и только ради хайпа и «повышения продаж» они назвали его «асинхронным программированием». хотя это ни то ни другое.
в части документации — я за ними лет 20 наблюдаю и поверьте мне — они легко пойдут на подмену понятий и назовут «теплое» «мягким», если это повысит продажи, или поможет сформировать в головах своих разрабов некую «узкокалейность майкрософтвей», наплевав на то, что во всем остальном мире это именно «теплое».
узкокалейность мышления — это примерно как с 1с — но последним хоть простительна узкокалейность, потому что у них свои уникальные механизмы (кстати, очень грамотно методически продуманные), и они не создают путаницу в терминах — «регистры учета» вот есть только в 1с, а общепринятые термины импользуют именно так, как это принято везде. вот1 или вот2. это понимание точно такое же как скажем в js.
на мисте, кстати, очень правильная фраза есть:
1с не реализовала неявное преобразование обычного кода в асинхронный, переложив тяжесть реализации асинхронности на программиста.
.
а вот майкрософт, похоже… реализовало. но вот что?)))
То, что вы называете "асинхронным программированием" с легкой' руки майкрософта, никакое не асинхронное програмирование, а скорее «неявное преобразование» обычного/синхронного кода во что то иное при компиляции.
теоретически, байткод может быть и асинронным, но на этот счет в указанной документации нет ни каких иных признаков, кроме «самопровозглашения что это мол асинхронное»: нет ни слова про обработчики событий, ни коллбеки…
есть, повторюсь, некая «регистрация продолжения»(continuatiin)" но такого технического термина нет, и что имеется в виду — никто не знает, и додумки ваших коллег про то что это выкидывается в коллбек-функцию — пока не подтверждены ничем.
сейчас, снова повторюсь, я бы классифицировал await/async как некий мехапизм «отложенных заданий».
Но это никак не асинхронный механизм.
Потому что там даже «асинхронного запуска» (типа запустили, оно начало работать, а мы отвалились) нету — потому что и параллельности то нет: согласно опять же этой документации, асинк / await не требуют многпоточностиок значит он не выполняется параллельно. последнее кстати, очень подозрительно и смахивает на ошибку.
я конечно не знаю деталей этой магии, но фраза
Асинхронные методы не требуют многопоточности, поскольку асинхронный метод не выполняется в своем собственном потоке. Он выполняется в текущем контексте синхронизации и использует время в потоке, только когда метод активен
… wtf?! вы серьезно?)))
так в каком потоке выполняются асинк-методы, из какого потока они выбирает время, если многопоточности нет, а в своем потоке он не выполняется. есть тайный тайный поток, про который забыли рассказать в документации и который не входит в понятие многопоточности? (это как история с пользователем Администратором, который на самом деле не совсем администратор, и может не всё, а есть еще более «администраторный администратор»)
или мс научились выполнять машинный код вне потока / вне времени / вне процессора?))) предположим, они используют свободное время потока, что бы в нем в фоне выполнять таски, наподобии того, как процессор делит время между задачами для эмуляции мультизадачности? ок. но это все равно выполнение таска в каком-то потоке. не блокирующее, но в потоке, а они говорят что нет, ибо мультипоточности нет.
в общем я не знаю кто кого обманывает, но, как минимум, называть использование отложенных заданий, с хитрым «магическим» процессом исполнения — асинхронным программированием — это подмена понятий.
Нет, они одинаковые. Трансформации, компиляция и все прочее не может менять логику.
Вы о какой логике говорите? Логика бывает разного уровня.
Если о логике и поведении описанном в коде высокого уровня — то оно сохраняется.
Но то как это поведение будет отражено в машинные инструкции — и по какой логике они будут работать — это может как сильно отличатьcя как от ваши представлений, так и сильно разниться от компилятора к компилятору.
Более того, логика работы исходного кода и логика работы машинного кода — они обязаны быть разными. Но обязаны реализовывать одинаковое поведение.
Например, на уровне кодов процессора нет никакого ООП и наследования.
О какой одинаковости логики вы вообще можете говорить, если логика работы вашего исходного кода построена на ООП-понятиях?
Сохраняется поведение, но даже не всегда детали логики исходного кода.
Посмотрите мой ответ https://habrahabr.ru/post/334964/#comment_10352244
и скажите — оптимизирущие компиляторы — они какую логику меняют? и что они вообще меняют?
ну на другой вопрос про разную реализацию await- тоже хотелось бы услышать ответ. спасибо )
Вообще-то компиляция это процесс отображения одного представления кода в другой. Логику выполнения компилятор не трогает, более того, если вдруг такое случайно происходит, то это баг и его очень быстро чинят.
Не совсем так))
Если быть более точными — компилятор реализует поведение, описанное на языке высокого уровня, с использованием языка более низкого уровня.
А вот какая логика будет использована на этом низком уровне — на уровне машинного кода или байткода — это уже его личное дело, покуда он остается в границах ожидаемого поведения, описанного языком высокого уровня.
Вот возьмем оптимизирующий компилятор — если поведение не изменится, он может вообще выкинуть всю логику расчета внутри вашей функции, и сразу выдавать на выход константу. Если, конечно, он обнаружит, что вне зависимости от входных параметров всегда получается одно и то же число.
Он легко может начать не умножать или суммировать, а дергать сдвиги, или, скажем, развернет циклы, если посчитает что так будет лучше. У вас в исходном коде — «визуально-однопоточный» циклический код, а на уровне машинного кода — 4 линейных параллельно исполняющихся цепочки.
Или, что скорее всего происходит и смущает вас — превратит синхронный код с await, в лапшу последовательно вызываемых асинхронных функций, связанных callback-ами.
А другой компилятор, может легко сделать не коллбеки, а 3 потомка и семафоры. Ведь согласитесь, await можно легко «сделать на семаформах».
Поведение программы, в обоих будет одинаковое, а логика и структура работы машинного кода (или байт кода) — разная.
И вот в такой ситуации — когда у нас реализация одного поведения, может быть построена на разных принципах, разной логике — скажите — как классифицировать сам исходный код? — по структуре его поведения, или по структуре того, что получается на выходе компилятора?
Вы, зачем-то, уцепились за выход компилятора. Вы уверены что это правильно?
Но именно так работает async/await в Scala/C# и JS — вешает весь код дальше в колбек. На Future, Task и Promise соответственно.
Не находите, что все ваши рассуждения в этой ветке теряют смысл?
Вы зачем-то смешиваете логику работы откомпилированного байт-кода (после оптимизации, преобразований и трансформации) и логику исходного кода. Они могут быть разные.
Исходно, как я помню, мы говорили именно о логике исходного кода, и о том, что именно «синхронный» код позволяет описывать многие вещи проще и быстрее, чем событийно-ориентированный, асинхронный подход, потроенный на обработчиках и call-back.
и так:
Исходный код с использвоанием await — синхронный.
Байт-код/машинный код может быть каким угодно. И это не отменяет синхронности исходного кода.
Или вот для аналогии ещё пример: если я написал синхронные обертки над асинхронными функциями с call-back — то та часть исходного кода, которая использует обертки — синхронная. Вне зависимости от того, что внутри обертки — асинхронные функции.
или вот ещё загадка:
У меня есть абстрактный класс с одной функцией waitForBytes() которая не должна отдавать управлениедо момента своего окончания. Далее, я реализовал интерфейс в 2-х потомках — в одном я использвал синхронной функции, а в другом — на синхронных функциях и на асинхронных callback.
Скажите — код который использует интерфейс — он синхронный или асинхронный? если думать о том, что лежит под функцией, а не над тем, как оно должно себя вести, то у вас возникает ситуация, что классификация участка исходного кода будет динамически меняться. Что есть бред.
Вообще асинхронность подразумевает, что что-то происходит независимо от основного потока выполнения. Использование await соответствует этому определению, потому что фактически обозначает:
определение не полное, именно поэтому вы путаете многопоточность и асинхронность.
Асинхронность (в случае локального, выполняющегося на одной машине кода) как правило говорит о том, что вы умеете реагировать на события/сообщения/уведомления от «того, что происходит независимо от вас» — когда что-то стороннее начинает вас уведомлять — и у вас как правило есть «обработчики»/«подписки»/«хуки»/«коллбеки»… — которые будут вызваны когда событие произойдет).
А если вы останавливаетесь на текущей инструкции, до тех пор пока не выполнится что то независимое от вас — это синхронный код.
Вы сами синхронищируетесь с чем-то — вне зависимости от того, на что вы смотрите или за чем вы следите.
То, что после await, выполнится тогда, когда задача, на которой сделан await, завершится (что является асинхронным событием). А сейчас возвращаем управление тому, кто нас вызвал.
завершение процесса — не стоит называть асинхронным событием.
Вот если бы ваш таск присылал вам в случайные моменты времени сообщения, и вы на них реагировали — это было бы асинхронным событием.
А так — это поведение, сходное с обычным «семафором».
Сравните вашу фразу с фразой "то, что после «вызова mуSemaphore.release(), выполнится только тогда, когда сосдений поток освободит семафор».
Но семафоры — это обычная синхронизация потоков, а ни какая ни «асинхронность».
И по-вашему, если я начал долгую асинхронную операцию IO, потом долго что-то считал, и потом «жду» результата начатой ранее операции через await — это типа все синхронно?
это запуск потока с последующей синхронизацией потоков.
И да, это, по логике/стилю работы работы — синхронный код.
Приведите пример «асинхронного кода» в вашем понимании.
а-синхронный код, в классическом, верном, понимании — это суть, событийно ориентированный код, который построен на колл-беках и/или обработчиках событий
примеры асинхронного апи: WinApi функции работы с последовательными портами, в которые вы передаете ссылку на функцию, которую надо вызывать, когда на вход поступят байтики. Qt-шные сигнал-слоты. Промисес в js (потому что вы передаете им функцию/ссылку на функцию)
int main()
{ ...
serial->setOnByteIncomeCallBack(&onByteInome);
serial->writeBytes(....);
}
int onByteInome(byte bytes[])
{ ...
}
Тут ситуация в чем — просто документации мало.
т.е. хорошо что оно есть, но это только начало.
Эта документация и стандарт языка воплощены в виде автоматических тестов?
Есть процесс сертификации сторонних реализаций котлина на предмет совместимости? Если вы обеспечите процесс сертификации под каждую версию, то и вопросы обратной совместимости будут выявляться на раз-два. Если нет — то что — остается «верить на слово»?
Если вспомнить историю, то (фактически) отсутствие процесса сертификации привело к тому, что, например, разные версии руби под разные платформы и среды не полностью совместимы друг с другом. А про разнообразие сишных не совместимых друг с другом компиляторов — помолчу — это «притча во языцах».
Если противопоставить джаву этому хаосу, то у джавы, например, есть процесс сертификации компилятора/джавамашины.
Вы же, по крайней мере пока, предлагаете «наслово поверить документации» и обещаниям. Но, повторюсь, чем они подтверждены? Заверениями что внутренние процессы компании производителя это обеспечивают? ага… 3 раза вам поверили.
Если вы предлагаете переходить на другой язык, причем _полностью_, надо нечто большее — например механизм обеспечения гарантии того, что кто-то другой может производить 100%-совместимые компиляторы. Почему это важно? Сегодня JetBrains есть, а завтра обанкротились. А нам что делать с туевой массой кода на хйповом котлине? Где вот скажем Borland со своим Delphi? «а нигде», образно говоря. В былые времена все и всё на дельфятине писали.… огогооо!… С джавой же ситуация кардинально другая — джаву, извините, не только Oracle поддерживает. Тут и сообщество, и IBM… т.е джаве есть хоть какая-то уверенность в завтрашнем дне. А в котлине?
И вот к JetBrains — вопрос — как они собираются обеспечивать долгую жизнь котлину? обещаниями и документацией? нуну…
SUN, имхо, в свое время понимали эту проблему, и сделали спеки полными и отрытыми. В том числе был создан, в конце концов и процесс сертификации сторонних джава-машин. И это, в том числе, обеспечило распространение джавы, «буквально везде», а в купе с обратной совместимостью — позволило стать промышленным стандартом. После них, по моим сведениям, никто другой такой подвиг не повторил.
И так… процесс сертификации компиляторов котлин от других производителей.
Он есть? Потому что это один из немногих, действенных способов обеспечить гарантии совместимости. Если у вас есть другие мысли о том как это гарантировать кроме как «поверить на слово производителю» — предлагайте.
Аналогия интересная, но не совсем.
Тут скорее вопрос о том, как производитель обеспечит совместимость с новымми версиями джавы, и я, признаться, надеялся, что вы скажете, что либо типа «они используют те возможности джава6 которые остались неизменными на протяжении 6-7-8-9 версий… ». Ну в варианте, когда вы используете Java6 и последнюю версию компилятора котлин конечно…
Но ничего подобного не прозвучало. Вы предлагаете, повторюсь, довериться разработчикам?
Если посмотреть в спеки различий между java6 и java7 то в принципе становится понятно, почему, некоторые проекты имеют проблемы с поддержкой новых версий джавы. Вот скажем
забавныйпример — aNimble — ныне мертвое продолжение другого ныне мертвого проекта «Open Source Requirements Management Tool». написано под GRAILS… и вот факт такой: то что лежит на sourceforge.net — байтвод, джарники — это всё не работает под Java7. Только под Java6.Почему так? не знаю… то ли они рефлекшен пользуют для доступа к приватным фунциям (вам разве сразу не говорили что так делать не надо?) или их логика работы завязана на порядок выдачи функций класса в рефлекшен-функциях? (а у вас в доках разве гарантирован порядок выдачи элементов?)…
Но на своей шкуре проверил — оно работает только под java 6.
И вот глядя на ЭТО, у меня и возникает вопрос — как именно производитель котлина собирается обеспечивать совместимость с Java 6|7|8|9|10? Какие методы обеспечения совместимости или хотя бы методы выявления несовместимостей… а вы мне про бинарную совместимость байткода. Ну не про это же речь.
Вот с джава все понятно — есть сертификация сторонних компиляторов и систем/сред/программ… а что с котлином и JetBrains?
Я не про совместимость с Java 6. Я про совместимость версий языка — старых версий с новыми.
Вот скажем, как авторы котлина собираются обеспечить гарантии того, что когда выйдет версия 1.3, вам не потребуется перекраивать код уже написанный на котлине 1.2?
Ну и… «клятвы» — это хорошо. Но «где ваши доказательства»?
Есть ли для котлина полная спецификация языка с детальным описанием поведения каждой конструкции, как это есть для Java и Java-машины?
Вот в джаве описанные вещи обеспечиваются именно детальной спекой, с последовательным включением в эту спеку всех оговорок и исключений, связанных с поведением старых версий джавы на новой машине и в окружении новых фич языка.
А что с котлином?
Ну, вы же понимаете, что это не доказательно? Хелло-ворды, вот скажем, всегда везде работают. Но мы же не про них говорим.
Извините, еще раз, за язвительность, но:
1) означает ли «100%-я совместимость» с java, что байткод, собранный компилятором котлина на 6й джава машине будет работать на 7й без пересборки? (замените цифры 6 и 7 на актуальные или вами любимые по возрастанию). A если будет, то будет ли он работать точно так же?
2) кто гарантирует что новые версии котлина будут 100% обратно совместимы со своими предшественниками? будет поддерживаться несколько веток котлина как это (все еще?) происходит с питоном или авторы котлина просто откажутся от поддержки старых версий, написав письмо вида «извините, мы знаем, что все еще не можете перейти на новую версию из-за проблем с обратной совместимостью в языке, и большого объема ваших проектов, но (нам пофиг) мы снимаем старую версию с поддержки», как это было с руби?
Скептик внутри меня говорит, что есть серьезное подозрение, что с точки зрения идеологов котлина, ни первое ни второе решать корректно «совершенно не обязательно», потому что «это всё это уже 100 раз видели» на примере других «байткод-совместимых языков», разных «убийц джавы» и многих других хороших и не очень языков.
А если не ответить правильно на эти 2 вопроса, это означает что это никакого большого промышленного будущего у этого языка нет, и говорить о котлине как о заменителе джавы нельзя. равно как и писать большие, долгоживущие проекты тоже «опасно» (банально есть риски отхватить тружноотлаживаемые проблемы при смене версий). Сначала — удобный синтаксис, приятные фичи… а потом…
Ну так как дела у котлина «с этим»?
скажем «Задачи с собеседований (web front-end)».
А то я уже приготовился читать TOP10-подборку маразматическо-смешных вопросов, которыми оные HR от излишнего рвения любят иногда грузить подателей резюме… а тут банальная js-ина)
— Кстати, про css-центрирование по горизонтали и вертикали разве ни разу не спросили?
А я бы спросил. Особенно после того, как полез я тут выяснять как это делать… и отгреб на 5 разных сайтах 25 разных вариантов, из которых у меня не получилось запустить ни один. Я не очень силен в css, да. А получилось, кстати, запустить код из комментариев.
Вот вы бы как сделали центрирование в ячейке (div) который преобразует внутреннюю модель таблицы в визуальное представление? В свойствах ячейки таблицы (в модели) есть свойства valign и halign со значениями 'start', 'middle' и 'end'. Размеры содержимого ячейки и внешнее обрамление (за границами вашего div) могут быть любые. Надо что бы ваше позиционирование работало всегда.
… но вот генерировать текст смс с суммой операции в момент совершения операции, а баланс брать на момент отправки смс — это, возможно, самое глупое что можно придумать в смс-информировании ))
потому что пока вы там «прокачатете смс по очередям» — я сделаю ещё пяток операций и в итоге мне уже около полугода периодически приходят замечательные сообщения типа «поступление 20 000.00 рублей, баланс 10.00 рублей» ))
поправьте сначала это, а уже потом хвалитесь «большими данными». ну серьезно. <_<
&$#%@%$!..., простите, «нехорошие люди» так и делают.geektimes.ru/post/272592
www.linux.org.ru/news/linux-general/713633/page1
И все бы ничего, но список патентов — не оглашается.
А в тех случаях когда список всплывает — оказывается, что эти патенты — prior-art в лучшем случае.
Прямо таки слышится вопль «оскорбленного глупыми HR-ами» «простого it-работника», который «просто работает свою работу», и которого обижает сравнение с «увлеченными своим делом», вплоть до того, что он сравнивает их с «роботами напивающимися в стельку каждую пятницу»? <_<
А по мне так, что «просто работать свою работу» по часам — это как раз и есть «быть роботом». Но не суть) такие простые работяги тоже очень нужны. На них очень многое держится.
… а мне одному показалось, что HR-ы, которые «обидели» автора — тоже «просто работники, у которых есть работа, и они её работают, с часовым перерывом на обед», не очень вдаваясь глубоко в детали?
Они витают в своих мифах про «увлеченных разработчиков»… — впрочем, равно как и автор, который думает, что на рабочем месте разработчика ПО, его будут ценить за писательство/художества/увлечения (и, конечно же, а как иначе выразить это уважение — поднимут из-за этого его з/п ?!)
Получается, он, «простой работник», не доволен тем как поступают «другие просто работники» (но уже в роли 'HR') — и у которых (как и у автора текста) нет желания погружаться в суть вопроса чуть более чем на 8 часов?
И, вот вопрос: как предполагается погрузиться в суть какого-либо серьезного вопроса, если не «переспать с проблемой», если постоянно переключать мозг на десяток других задач — то там у парня «собачий бизнес», то походы, то искусство, то ещё десяток других увлечений… когда его мозг успеет настроиться на решение?
В случае серьезных задач — за 8 часов, вы можете едва улучшить то, о чем вы думали вчера вечером, стоя в душе, и то, над чем ваш мозг думал во сне. И увы, именно такой ценой люди двигают/решают сложные задачи. И да, таких единицы. Для них, решение таких задачек — это их «хобби», они не переключаются на «собачий бизнес» выходя с работы. И да, в такой сложной области как IT — именно такие люди становятся «легендами» и «звездами». И, согласитесь, понятно, что за ними охотятся любые HR.
Но крайне необходимо понимать, что «то, что делают звезды» — не отменяет ценность и важность труда тех, кто рутинно оттачивает и реализует ключевые решения «увлеченных». Тут нет лучших и худших. Тут есть 2 разных, дополняющих друг друга стиля.
Но, почему, как мне показалось, этого не понимают не только упомянутые HR-ры, но и сам автор?
Получается, что «по вашей версии бритвы оккама» — оптимизирующий компилятор ничего не меняет? но по факту же он «что то» меняет — программа начинает работать быстрее, меньше ресурсов используется.
Так какую логику он меняет — можете описать? не уходите от ответа.
при этом отмечу, что никаких асинхронных call-back в этом случае нет. нет ни обработчиков, ничего. Просто конвеер задач на входе планировщика.
от такой реализации — исходного ли «синхронность» исходного кода?
вот как раз в документации то, ничего про callback не сказано.
Более того — там несется некая ахинея про код, выполняющийся вне основного потока, но без потока. Я согласен что возможно, async таск выполняется вне потока вашей программы, а в неком «сервисном потоке», который предоставляется .net-средой -исполнения. Но если у вас есть вычисления внутри async функции, они будут выполняться внутри потока.
А в документации которую вы показали рассказывается о некой «магии», и ни слова о том, как это действительно проиходит. Потому вы или покажите офф. документацию где явно сказано, что там действительно последующая часть кода выносится в call-back-функцию, или признайте что вы «не совсем правы». Потому что повторюсь — в документации рассказывается о неких «contonuation» — а что это — нигде не написано.
Более — того. По большому счету не важно, что там внутри. Считаете что там создается асинхронный байткод — ок, я допускаю, я не против. Я против того, что бы на основании того, _во_что_ превращается await в машинном коде, классифиировать исходный код.
Await позволяет вам создавать код в синхронном стиле, который при компиляции создает асинхронный. Да, он добавляет в эту синхронность особые точки в которых поток может заняться другими задачами пока выполняется код вызванный через await. Да, такое особое свойство. Но код последователен, синхронен, событий и обработчиков в нем не объявлено. Значит это синхронный код.
А то что вы считаете что при синхронности должен «блокироваться поток» — это следствие того, что вы привязываете определение к конкретной реализации.
бритва оккама, говорите? если код построен по логике последовательного выполнения операций, синхронного, выглядит как синхронный, выполняется как синхронный. подчинятся логике синхронного — значит код синхронный.
Исходный код. но не байт код, который получаем в итоге компиляции.
давайте ещё раз)))
то что await, приводит к тому, что перебор операций исходного кода в данной точке приостанавливается (но поток не блокируется) — это хорошее свойство но с точки зрения поведения, эта логики кода, к понятию «асинхронность» он имеет отношение косвенное, связанное только с тем как оно реализовано.
Повторюсь — как вы будете классифицировать этот код, если он будет собран компилятором, который разнесет ваш код на 3 Runnable (до await, сам await, после await ), сложит их в очередь, и поставит на выполнение для некого планировщика? плаировщик будет брать на выполнение следующий раннабл только тогда, когда выполнится предыдущий.
первый и последний runnable он выполнит в gui потоке, сам await — в сервисном/фоновом.
Поведение будет точно таким-же.
«GUI-Поток» не блокируется, операции выполняются строго в нужном порядке, ждут друг друга без блокировки gui потока.
Классификация исходного кода изменится или нет? можете ответить на этот вопрос?
DMA — это не выполнение вычислений описанных у вас в async функции.
Когда у вас вычисления внутри вызываемой через await функции — они выполняется внутри какого-то потока.
и выполняемое операционкой действия глубоко внутри — тоже формально прикреплены к какому-либо потоку. то не имеет отнощения к мифу о внепоточности кода внутри await
мозилла, в отличии от сишарпа, возвращает промис, в который вы подставляете функцию-обработчик, которая должны быть вызвана.
это построение асинхронного кода. в отличии от «не-явных преобразований в c#».
асинхронность, это event-driven стиль построения системы. коллбеки — это наиболее частый способ указания на функцию обработчик.
у вас нет в коде событий и функции обработчика событий? значит ваш код — ни разу ни асинхронный, потому что он построен не по асинхронной логике.
то что появляется в результате неявных преобразований в байткоде при компиляции — дело совершенно третье (там действительно может быть полный аналог мозиловского асинка, но может и нет), и это попадает под тему замены логики работы при компиляции.
а то, что вы считаете что есть как-то по другому, так это итог замены понятий и путаницы в терминологии авторов сишарпа, и несоответствия этих теринов, тем, которые используют все остальные.
верноне верно, потому что await не регистриурет никаких действий, и его поведение, на уровне исполнния последовательности строчек кода, ничем не отличается от работы семафора.
да, await волшебным образом не блокирует текущий поток, но это иные свойства, не связанные event-driven стилем разработки.
асинхронность возможна с одним потоком, да.
действия выполняющиеся вне какого-либо потока — нонсенс, противоречит основам работы операционной системы. это базис. код всегда выполняется в каком либо потоке. сисемном, фоновом, еще каком. но если процессор исполняет код, значит какойто поток есть. могут быть действия или вычисления без потоков, но тогда не на процессоре. у нас наши коллбеки выполняются
или у вас есть ссылка на теорию операционных систем или ещё что что? бложики «разных специалистов» — это конечно хорошо, но подмена понятий — это уже плохо.
еще раз повторюсь: то, что await (вероятно) приводит к асинхронному байткоду — это результат компиляции. я могу вам постороить компилятор, который будет преобразовывать код в набор runnable (скажем до await и после) и выполнять эти раннаблы в пуле потоков, итоговое поведение будет точно точно таким же — это не будет блокировать ваш гуи поток, все что после await будет выполняться строго после завершния того раннабла, в который я засуну сам await, но это ни разу не будет асинхронный или синхронный байткод. это нечто иное.
на остальную «лапшу» отвечу попозже.
это сохранение поведения, а не логики работы.
да, поведение не будет противоресить той логике которую вы заложити в исходный код, но не факт что логика работы, структра кода будет такими же.
вот вам пример одинакового поведения, но разной логики: если насекомые используют магнитные поля что бы находить север, а птицы ориентируются по полярной звезде, и при этом в пасмурную погоду они не летают «потому что стремно» — разныцы вы в их поведении не увидите.
так и компилятор. он сделает такие реобразования, о которых вы и не помыслите, но поведение останется таким же.
разберитесь с разными уровнями логики.
После «разворачивания циклов» у вас циклов как таковых не будет в байткоде, и не будет у вас ни джампов ни лейблов. Будет простой линейный код.
О какой «одинаковой логике» вы говорите? В сорсах у вас цикл и условия, а в байткоде — линейный поток вычислений без джампов и условий. это сохранение логики? О сохраннии какой именно логики вы говорите? не позорьтесь)))
или классифицируйте в терминах вашей вселенной, что именно делает с кодом оптимизирующий компилятор, и какую логику (или что именно?!) он меняет?
в указанной вами статье от асинхронности только название, самопровозглашение «про асинхронность», да схожая с асинхронностью идея «отложенного задания» которая фактически описывается под видом «асинхронности».
прочитайте внимательно содержимое, ищите признаки описывающие асинхронность, и судите не по заголовку а по содержимому…
например там нет ни слова про коллбеки, или событийность, нет ни слова про асинхронный запуск (коим можно конечно классифицировать запучк процедуры в параллеьном потоке, но в асинк… типа же нет потоков(?)...)
там есть некая «регистрация продолжения (»continuation") про которыую никто не знает что это именно аткое.
судя по _содержимому_ это не асинхронность. это нечто другое. это некий механизм отложенных заданий, с принудительным вызовом задания к исполнению в момент await, с отсутствием блокировок, который обладает некими плюсами которыми обычно обладает асинхронный код, но обладающий логикой и стилем синхронного.
и только ради хайпа и «повышения продаж» они назвали его «асинхронным программированием». хотя это ни то ни другое.
в части документации — я за ними лет 20 наблюдаю и поверьте мне — они легко пойдут на подмену понятий и назовут «теплое» «мягким», если это повысит продажи, или поможет сформировать в головах своих разрабов некую «узкокалейность майкрософтвей», наплевав на то, что во всем остальном мире это именно «теплое».
узкокалейность мышления — это примерно как с 1с — но последним хоть простительна узкокалейность, потому что у них свои уникальные механизмы (кстати, очень грамотно методически продуманные), и они не создают путаницу в терминах — «регистры учета» вот есть только в 1с, а общепринятые термины импользуют именно так, как это принято везде. вот1 или вот2. это понимание точно такое же как скажем в js.
на мисте, кстати, очень правильная фраза есть:
.
а вот майкрософт, похоже… реализовало. но вот что?)))
То, что вы называете "асинхронным программированием" с легкой' руки майкрософта, никакое не асинхронное програмирование, а скорее «неявное преобразование» обычного/синхронного кода во что то иное при компиляции.
теоретически, байткод может быть и асинронным, но на этот счет в указанной документации нет ни каких иных признаков, кроме «самопровозглашения что это мол асинхронное»: нет ни слова про обработчики событий, ни коллбеки…
есть, повторюсь, некая «регистрация продолжения»(continuatiin)" но такого технического термина нет, и что имеется в виду — никто не знает, и додумки ваших коллег про то что это выкидывается в коллбек-функцию — пока не подтверждены ничем.
сейчас, снова повторюсь, я бы классифицировал await/async как некий мехапизм «отложенных заданий».
Но это никак не асинхронный механизм.
Потому что там даже «асинхронного запуска» (типа запустили, оно начало работать, а мы отвалились) нету — потому что и параллельности то нет: согласно опять же этой документации, асинк / await не требуют многпоточностиок значит он не выполняется параллельно. последнее кстати, очень подозрительно и смахивает на ошибку.
я конечно не знаю деталей этой магии, но фраза … wtf?! вы серьезно?)))
так в каком потоке выполняются асинк-методы, из какого потока они выбирает время, если многопоточности нет, а в своем потоке он не выполняется. есть тайный тайный поток, про который забыли рассказать в документации и который не входит в понятие многопоточности? (это как история с пользователем Администратором, который на самом деле не совсем администратор, и может не всё, а есть еще более «администраторный администратор»)
или мс научились выполнять машинный код вне потока / вне времени / вне процессора?))) предположим, они используют свободное время потока, что бы в нем в фоне выполнять таски, наподобии того, как процессор делит время между задачами для эмуляции мультизадачности? ок. но это все равно выполнение таска в каком-то потоке. не блокирующее, но в потоке, а они говорят что нет, ибо мультипоточности нет.
в общем я не знаю кто кого обманывает, но, как минимум, называть использование отложенных заданий, с хитрым «магическим» процессом исполнения — асинхронным программированием — это подмена понятий.
Вы о какой логике говорите? Логика бывает разного уровня.
Если о логике и поведении описанном в коде высокого уровня — то оно сохраняется.
Но то как это поведение будет отражено в машинные инструкции — и по какой логике они будут работать — это может как сильно отличатьcя как от ваши представлений, так и сильно разниться от компилятора к компилятору.
Более того, логика работы исходного кода и логика работы машинного кода — они обязаны быть разными. Но обязаны реализовывать одинаковое поведение.
Например, на уровне кодов процессора нет никакого ООП и наследования.
О какой одинаковости логики вы вообще можете говорить, если логика работы вашего исходного кода построена на ООП-понятиях?
Сохраняется поведение, но даже не всегда детали логики исходного кода.
Посмотрите мой ответ https://habrahabr.ru/post/334964/#comment_10352244
и скажите — оптимизирущие компиляторы — они какую логику меняют? и что они вообще меняют?
ну на другой вопрос про разную реализацию await- тоже хотелось бы услышать ответ. спасибо )
Если быть более точными — компилятор реализует поведение, описанное на языке высокого уровня, с использованием языка более низкого уровня.
А вот какая логика будет использована на этом низком уровне — на уровне машинного кода или байткода — это уже его личное дело, покуда он остается в границах ожидаемого поведения, описанного языком высокого уровня.
Вот возьмем оптимизирующий компилятор — если поведение не изменится, он может вообще выкинуть всю логику расчета внутри вашей функции, и сразу выдавать на выход константу. Если, конечно, он обнаружит, что вне зависимости от входных параметров всегда получается одно и то же число.
Он легко может начать не умножать или суммировать, а дергать сдвиги, или, скажем, развернет циклы, если посчитает что так будет лучше. У вас в исходном коде — «визуально-однопоточный» циклический код, а на уровне машинного кода — 4 линейных параллельно исполняющихся цепочки.
Или, что скорее всего происходит и смущает вас — превратит синхронный код с await, в лапшу последовательно вызываемых асинхронных функций, связанных callback-ами.
А другой компилятор, может легко сделать не коллбеки, а 3 потомка и семафоры. Ведь согласитесь, await можно легко «сделать на семаформах».
Поведение программы, в обоих будет одинаковое, а логика и структура работы машинного кода (или байт кода) — разная.
И вот в такой ситуации — когда у нас реализация одного поведения, может быть построена на разных принципах, разной логике — скажите — как классифицировать сам исходный код? — по структуре его поведения, или по структуре того, что получается на выходе компилятора?
Вы, зачем-то, уцепились за выход компилятора. Вы уверены что это правильно?
Исходно, как я помню, мы говорили именно о логике исходного кода, и о том, что именно «синхронный» код позволяет описывать многие вещи проще и быстрее, чем событийно-ориентированный, асинхронный подход, потроенный на обработчиках и call-back.
и так:
Исходный код с использвоанием await — синхронный.
Байт-код/машинный код может быть каким угодно. И это не отменяет синхронности исходного кода.
Или вот для аналогии ещё пример: если я написал синхронные обертки над асинхронными функциями с call-back — то та часть исходного кода, которая использует обертки — синхронная. Вне зависимости от того, что внутри обертки — асинхронные функции.
или вот ещё загадка:
У меня есть абстрактный класс с одной функцией waitForBytes() которая не должна отдавать управлениедо момента своего окончания. Далее, я реализовал интерфейс в 2-х потомках — в одном я использвал синхронной функции, а в другом — на синхронных функциях и на асинхронных callback.
Скажите — код который использует интерфейс — он синхронный или асинхронный? если думать о том, что лежит под функцией, а не над тем, как оно должно себя вести, то у вас возникает ситуация, что классификация участка исходного кода будет динамически меняться. Что есть бред.
Асинхронность (в случае локального, выполняющегося на одной машине кода) как правило говорит о том, что вы умеете реагировать на события/сообщения/уведомления от «того, что происходит независимо от вас» — когда что-то стороннее начинает вас уведомлять — и у вас как правило есть «обработчики»/«подписки»/«хуки»/«коллбеки»… — которые будут вызваны когда событие произойдет).
А если вы останавливаетесь на текущей инструкции, до тех пор пока не выполнится что то независимое от вас — это синхронный код.
Вы сами синхронищируетесь с чем-то — вне зависимости от того, на что вы смотрите или за чем вы следите.
завершение процесса — не стоит называть асинхронным событием.
Вот если бы ваш таск присылал вам в случайные моменты времени сообщения, и вы на них реагировали — это было бы асинхронным событием.
А так — это поведение, сходное с обычным «семафором».
Сравните вашу фразу с фразой "то, что после «вызова mуSemaphore.release(), выполнится только тогда, когда сосдений поток освободит семафор».
Но семафоры — это обычная синхронизация потоков, а ни какая ни «асинхронность».
И да, это, по логике/стилю работы работы — синхронный код.
а-синхронный код, в классическом, верном, понимании — это суть, событийно ориентированный код, который построен на колл-беках и/или обработчиках событий
примеры асинхронного апи: WinApi функции работы с последовательными портами, в которые вы передаете ссылку на функцию, которую надо вызывать, когда на вход поступят байтики. Qt-шные сигнал-слоты. Промисес в js (потому что вы передаете им функцию/ссылку на функцию)