Как стать автором
Обновить
18
0

«и швец и жнец...»

Отправить сообщение
Ожидал увидеть ConEmu хотя бы в комментариях. Поскольку не увидел, похоже, пора смотреть в сторону Windows Terminal.
Я вот чего не понимаю. Если нам важен порядок следования записей — мы добавляем ORDER BY. Если нам он не важен — не добавляем. Как тогда может прийти в голову мысль о сохранении порядка, который нам не важен?! Какого порядка, если мы его никак не определили?

Интересно, это у меня так мозги трансформировались от длительной работы с SQL, или всё-же некая логика в моих рассуждениях есть?
Но ведь математика базируется на ряде аксиом. Какие аксиомы выберем, такая математика и получится. Не могли бы Вы уточнить утверждение
Поэтому разумно отталкиваться, например, именно от математики, т. к. изучаемые ей объекты непосредственно существуют
именно в этом контексте?
Я не жаргонизмы имел в виду. И опечатки — это тоже не беда, всё нормально. Просто часто мне было трудно понять, что имеется в виду в том или ином случае.

Спасибо, что разделили абзацы — стало лучше))
Тема мне интересна, статья богата полезным материалом, рассуждениями. Но подача… Да, я активно с рефлекшном не работал. Но проекты были большие и разнородные. Последний раз писал на c# около года назад. Сижу и «гуглю», что же такое «IL эмиссия», почему её «лучше нафиг» и что же такое этот XD.

Когда до «CLR расчехляет ГЦ и понеслись фризы» дошёл, пытался понять, а не о сборщике ли мусора говорит автор. Потом дошло, что ГЦ — это транслитерированный gc.

И так далее. Приходится отрываться, додумывать, что же хотел сказать автор, искать что-то в Сети, иногда сообщать об опечатках… И потом, возвращаясь к статье, долго и мучительно искать то место, где закончил читать — абзацы-то друг от друга не отделены…

Извините, не смог себя заставить дочитать. Попозже сделаю ещё один «подход к снаряду»…
Я пытаюсь себя поставить на место обычного пользователя. (При чём тут, кстати, Cisco Webex и Google Meet?)

End-to-end шифрование в Zoom и правда есть (не знаю, на сколько это шифрование стойкое). Только для чатов.
Давайте посмотрим не на то, что на их сайте сейчас, а на то, что было, ну скажем, 25.03.2020. Вот выдержка:
Protecting your Meetings
The following in-meeting security capabilities are available to the meeting host:

* Secure a meeting with end-to-end encryption
...
Компания-таки утверждала, что «сквозное шифрование» (end-to-end encryption) для конференций у них ведётся.

Во всей шумихе с Zoom меня меньше всего интересует их маркетинг. Я уже как-то научился отфильтровывать балабольщину от действительных технических state-of-art.
Это делает Вам честь. А как же остальные пользователи, которые далеки от IT? То есть, «на клетке слона… надпись «буйвол»» — это нормально?

И (наверное) понимаете, что энтерпрайз решения защищаются от таких проблем контрактами в 50+ А4 страниц и SLA.
Я не автор статьи и про «энтерпрайз решения» ничего не писал.
С одной стороны, я понимаю, что пользователи сами виноваты. Но с другой — как-то это нехорошо, когда при настройках по умолчанию в твою конференцию может кто-то пролезть и, о чудо, записать её локально и потом выложить на всеобщее обозрение.

Под «модным словечком» «сквозное шифрование» (end-to-end encryption) понимается вполне конкретная функциональность, безотносительно того, что некоторые варианты её реализации явно тяжеловесны и есть проблема с подключением по телефонной линии. Если компания утверждает, что эта функциональность есть, а потом выясняется, что компания под этим «модным словечком» понимает нечто другое, то как это называется? Не забываем при этом, что утверждение о наличии этой функциональности даёт нехилое такое конкурентное преимущество. Да и пользователи, когда слышат «сквозное шифрование» — думают, что никто кроме участников конференции не может её расшифровать…
Жалко, что первое апреля прошло. Иначе было бы хорошей шуткой: «В рамках программы переведения с++ в „мейнстримовый язык“, от обеих форм операторов „++“ и „--“ отказались. Вследствие этого „с++“ тоже пришлось переименовать. По логике, просто отказались от „++“. Но потом кто-то подсказал, что язык с названием „с“ уже существует...»

А если серьёзно, код, который Вам не понравился — нормальный код для с. Да и для с++, в общем-то, тоже не вижу криминала.
aspid-crazy, автор изначально говорит, что цифры условны и с потолка. Тут абсолютно все цифры такие. Главное — понять поведение системы: вид графиков, управляемое превращение экспоненты в степенную функцию, как и на что влияют применяемые меры, почему они не профанация,… И я бы скорее обратил внимание не на «маловероятную» летальность, а на предел насыщения системы здравоохранения, о котором автор тоже говорит:
Пусть порог ее насыщения — одномоментно болеющие 10% популяции (это заведомо гораздо круче реальности)...
Автор показал, что он относится к сторонникам первой религии.
Нет.
У автора есть своя точка зрения, и он её отстаивает.
Нет.
Интригующе. Но не суть. Простите, что неправильно вас понял.
Что вами двигало, по крайней мере, при написании двух последних статей?
Желание посеять крупицу сомнений в каждом, кто по недомыслию примкнул к колонне марширующих строем. Много мнений — лучше одного, по крайней мере потому, что тренирует мозг необходимостью осознанного выбора.

Что-то подобное я и надеялся услышать. Спасибо. У вас получается «посеять крупицу сомнений в каждом» ;) Поэтому, собственно, и закинул плюс в карму после предыдущей статьи.

Ещё мне нравится ваш подход, никого не минусовать. Стараюсь тоже ему следовать.

Успехов вам, и жду следующих неоднозначных статей!
О! Ещё одна «холиварная» статья!

В моём понимании, существует как минимум две «религии». Сторонники одной «поклоняются» строгой типизации, сторонники другой — слабой или отсутствию типизации. Ярый достаточно опытный сторонник каждой «религии» приведёт массу сильных аргументов, почему именно его «религия» единственно правильная.

Автор показал, что он относится к сторонникам первой религии. Лично я являюсь, скорее, сторонником второй. Я понимаю, что могут существовать задачи, для решения которых более удобна слабая типизация или отсутствие типизации как таковой. Да, практически на каждое утверждение автора я мог бы привести контрпример или написать опровержение, но зачем? С одной стороны, из комментариев видно, что любая аргументация/контраргументация тут только провоцирует дальнейшие споры. У автора есть своя точка зрения, и он её отстаивает. С другой стороны, начиная писать контраргументы, я вроде как, начинаю пропагандировать свою «религию».

Строгая типизация, по-моему, является системой ограничений, которые позволяют в итоге существенно упростить _мне_ жизнь. Но они при этом остаются ограничениями, либо не достаточно сильно, либо вообще не упрощающими жизнь, с точки зрения сторонников другой «конфессии». Так что какой бы аргумент я не привёл, всегда можно сказать, что он недостаточно хорош, что цена слишком высока, что он вообще не верен,… etc.

Итак, я очень горд собой, за то, что подавил желание расписать тут, почему у меня другая точка зрения, привести соответствующие примеры,… И главное — я планирую не писать об этом статьи!

P.S. chapuza скажите, как вы выбираете, о чём будете писать? Что вами двигало, по крайней мере, при написании двух последних статей? Предыдущая ваша статья вызвала большой резонанс. Эта тоже, похоже, будет резонансной. Обе статьи, с моей точки зрения, являются провокационными. Но вашу карму я не минусовал, а даже вовсе наоборот. Статью тоже не минусую.
Async/await по сути синтаксический сахар для запуска функции в отдельном потоке, придуманный чтобы кода поменьше писать. Но правильно применять параллелизм в решении задачи все еще задача программиста.
В моём понимании, всё-таки многопоточность и асинхронность, это не совсем одно и то же. Да, асинхронности можно добиться посредством многопоточности. Но для асинхронности как таковой многопоточность не обязательна. Вот, в node, например, все наши асинхронные функции запускаются в одном единственном потоке. А с синтаксическим сахаром я согласен. Правда, без него, начинается кошмар.

balajahe ведь async/await неспроста «вирусный». Если мы предполагаем в коде наличие асинхронного вызова, то очевидно, что все предыдущие вызовы по стеку должны знать, что каждый вызов может быть преостановлен.

Теперь посмотрим на ваш пост. С одной стороны, мы хотим, чтобы была возможность асинхронно получить данные из медленного хранилища, с другой — жалуемся на непомерно большие расходы на асинхронность, когда по логике программы к медленному хранилищу обращаться больше не надо.

Такова цена асинхронности. Либо она есть (асинхронность), либо её нет.

Если у вас предполагается, что всё будет закэшировано, попробуйте раздельно заниматься заполнением кэша и использованием его. Может, вам и не нужно асинхронности — всё может прекрасно работать, скажем просто многопоточно?

Выше уже говорили, что более правильным подходом было бы кэшировать promise, а не объекты напрямую. Как минимум, создание одного promise можно было бы избежать. Умный runtime (jit) даже возможно что-нибудь оптимизирует.

P.S. В некоторых рантаймах можно извернуться и «избавиться» от асинхронности на каком-нибудь уровне, сделав синхронный вызов executor-а, который в других потоках выполнит всю асинхронную часть, заблокировав наш поток. Решение, по крайней мере для большинства моих задач, сомнительное. Нужно очень хорошо и не один раз подумать, прежде чем его использовать. Но для вашей задачи может быть подойдёт.
vladimir_dolzhenko поищу более ранний javadoc… Ну, или ссылку сотру, и вставлю прямым текстом…
Скорее, с этого момента hashCode пришлось записывать.
В пользу моей точки зрения говорит JDK-8213076 Pattern matching for switch...
Уели. Согласен.
Не нужно передёргивать, я говорил про байткод
Я написал то, как можно легко понять ваше высказывание. Поэтому, собственно, и абзац начал с: «По-моему, это утверждение слегка неосторожное».
Да, вчера ночью об «одиночке-ENUMе» даже и не вспомнил. Наверно, потому, что стараюсь жить без «одиночек». Ну а стюардесса изредка в каком-нибудь проекте возьмёт, да и всплывёт…
Спасибо, добавил.
Спасибо, согласен. Хотелось написать проще, вот и доупрощался. Сейчас починю.
Спасибо, про -XX:hashCode=4 я совсем забыл. Сейчас добавлю.

Версии java, начиная с которой поведение изменилось, в статье не указывалось.

Согласен, в данном месте следовало вставить оговорку, что это являлось особенностью конкретной jvm и спецификацией не требовалось. Сейчас вставлю.
Мы с вами говорим об одном и том же, только по разному. Вы отмечаете, что это не сделано потому, что было заявлено, что это сделано не будет. Я отмечаю, что реализовавать это было бы весьма проблематичто, поэтому, скорее всего, и было принято решение этого не делать. Им и со строками-то уже сильно выворачиваться пришлось. Ведь в конечном итоге, это не вызывает проблем с совместимостью, и, я думаю, много кто просил расширить конструкцию switch-case существенно больше, чем это было сделано.

Добавят в спецификацию разрешение использовать java.lang.Class — допилят и компилятор и VM.

В какой конкретно байткод это будет транслироваться — дело десятое.

По-моему, это утверждение слегка неосторожное. Складывается такое впечатление, что главное — это принять решение, а выполнимо ли оно с заданным качеством — «дело десятое»…

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность