Конкретно такую штуку я тоже смогу написать вам на Java с некоторыми ограничениями (в немалой части — из-за церемоний с аннотациями типов), и она иногда тоже будет работать — но вы не сможете её как-то с особой пользой применять пока не напишете всего остального лямбда-исчисления. Если мы продолжим в этом же духе общаться, то через некоторое обозримое количество итераций я напишу вам аналог Frege.
В контексте обсуждения, что функциональное программирование можно сделать поверх объектно-ориентированного, я не наблюдаю в ситуации принципиальной проблемы, ведь всё, в чём вы меня поправляете — следствие моего незнания Хаскеля, а не невозможности сделать его аналог поверх Java.
Безотносительно конкретной ситуации, руководитель не обязан иметь какого-то определённого образования. Чтобы руководить IT компанией, совсем необязательно уметь писать код — обычно нужно уметь хорошо руководить людьми. Частью такого умения является умение нанять хороших советников, которые уже имеют достаточно компетенции, и прислушиваться к мнению нанятых советников.
Корень проблемы здесь не в образовании — у меня стойкое ощущение, что именно нарушена связь руководителя с экспертами: либо их совсем нет, либо они недостаточно компетентны, либо их мнение просто игнорируется, если мнение неудобное.
Ну например, в Китае уже давно можно присесть за картинку с Винни Пухом. И в России тенденция как бы наметилась уже.
Или вы имеете в виду "когда лично меня будут присаживать за котиков, тогда и поговорим"?
С вопросами, повторяющимися дважды на странице и стопицот раз разжёваными в шапке темы
Это как раз показывает, что аудитория таких тем — обыкновенные люди, а не какие-то там специалисты в IT. Потому что как правило именно такие вот "обычные" люди почему-то просто принципиально не читают никакие мануалы, не ищут ничего в поисковиках, а любому способу получения информации предпочитают сразу задать вопрос и ждать пока лично им не ответят на него (и пофиг, что ответ на такой же вопрос был в предыдущем сообщении, продублирован в шапке темы и выплывает в модальном окне при нажатии кнопки "отправить", это всё было прокликано на автомате без включения мозга).
Композиция линз — это не "стандартная функциональная" композиция, потому что линза — это не функция. В функцию A->X нельзя передать X чтобы получить на выходе A. Линза — это пара функций (A->X) + (X->A), потому для линз композиция должна быть сделана специально, согласно определению линзы, что я и сделал. Что до "стандарта", строка
right.view.andThen(left.view)
в терминах Java уже вполне стандартная функциональная композиция, часть стандартной библиотеки.
перед удалением сериала заранее предупредят о том что он будет удалён
Сработает только если постоянно следить за какими-то каналами новостей и обновлений. Очередной источник шума о событиях, которые либо неинтересны, либо вы всё равно ни на что там повлиять не сумеете.
Я в целом понимаю желание делегировать поддержку серверов с данными кому-нибудь ещё, но это приходит с непропорциональным ограничением в возможностях контроля за содержимым сервера.
Если при наличии бесплатного варианта кто-то покупает ещё и платный, то жто говорит о том что платный чем-то лучше.
Или платный куплен для очистки совести, чтобы приобрести моральное право пиратить. Это распространённый аргумент в подобных случаях. Например, покупка игры после того, как я на пиратской версии убедился, что всё устраивает. Или покупка альбома исполнителя после скачивания его через торренты.
если какой-то сериал и удалят, то значит буду смотреть другие.
Похоже, ваша позиция дрейфует. То вы хотите остановить на телевизоре, и потом продолжить с планшета точно с того же времени (и это считаете проблемой хранить данные локально), то с полным пофигизмом заявляете, что если не сможете что-то смотреть, то просто посмотрите что-то другое. Стриминговые сервисы по определению не дают абсолютно никаких гарантий, что вы сможете куда-то там вернуться и продолжить — у них там, может быть, право на трансляцию истекло пока вы до туалета шли. Или пучок других причин, большинство которых владельцы вам и сообщать не станут. В то время как локальные файлопомойки такую гарантию не дают только в случае физической поломки самой коробки.
Возможно, здесь такое соображение: всем тогда было скучно, и чтобы скучно не было, нужно было что-то придумать. Придумывать что-нибудь — это навык, у вас он развивался, ведь нужно сделать некоторое усилие, чтобы видеть в отломанной щепке автомобиль.
Теперь для развлечений придумывать ничего не нужно, всё уже есть готовое, берёшь и развлекаешься — следовательно, такой же навык не развивается. Может, развивается какой-то другой, а может — вообще никакого не развивается. Сейчас, по сути, первое поколение, детей, которым "не скучно", и мы не знаем, это хорошо или плохо, когда дети не скучают — покажет только время. Возможно, в будущем детей специально будут держать на "голодном пайке" в смысле развлечений, в воспитательных целях.
Ну а вообще брюзжание о том, что "дети в наше время ужасны" даже на месопотамских табличках с клинописью находили.
сли, например, будет зафиксировано, что скорость передачи данных на устройстве пользователя отличается от заявленных характеристик тарифного плана, то автоматически будет заводится тикет в техподдержку. И далее уже сотрудники и специальные системы со стороны оператора будут выяснять что нужно сделать для пользователя — перенастроить роутер, протестировать линию связи или изменить сетевые настройки на устройстве клиента на корректные
Не хватало мне ещё звонков от техподдержки в духе "наша программа показывает, что у вас плохое качество соединения, пожалуйста, перезагрузите оборудование и перезвоните".
Что-то мне не особо верится, что "сотрудники и специальные системы" будут не из первой линии техподдержки.
Не совсем понимаю аргумент про точку. Точка — это синтаксис, не принцип.
В Java тоже можно синтаксически сделать "через точку", если Lens.compose сделать нестатическим — тогда первый аргумент будет this:
Оба-на. Я-то думал, есть какой-то алгоритмический смысл делать вывод hex-текста без условных переходов и типичных lookup-tables. Ну там, ускорение для процессорного конвеера кратное. Интересное что-нибудь, эдакое, на острие прогресса, вот это вот всё.
А оказывается это всё просто чтоб людей "мордой ткнуть", мол, раз они не подумали что правильное решение — это в системных шрифтах копаться — то они "не настоящие программисты". Задача на смекалку, уровня трёх лампочек и круглых люков, и вообще без практического смысла. Но при запрете создавать вспомогательные массивы в программе — вы в своём решении создали гигантский по сравнению вспомогательный шрифт, загрузили его в память и потратили несколько килобайт(и это минимум, глифы в шрифтах бывают большие) места вместо жалких size<char> * 16. То есть, вообще говоря, нарушили свои же условия. И при этом программа (hex-редактор, вроде?) потеряла пункт в настройках, который позволил бы пользователю установить такой шрифт, который ему будет удобнее.
Удачи вашей компании в поисках работников. Удача вам пригодится.
Этот мой вариант вверху композицию, боюсь, не поддерживает. Потому что я заточил его под мутабельные данные — это значит, что view сделать можно, а чтобы сделать store придётся (из)вращаться со специально заточенными под композицию линзами, что, очевидно, не тру. Если данные иметь иммутабельными, то пойдёт веселее. Cкомпозированная линза для Rect.topLeft.x в любом случае будет иметь тип Lens<Rect, Integer>:
class Point {
final int x, y;
Point(x, y);
Point withX(int value) {
return new Point(value, y);
}
Point withY(int value) {
return new Point(x, value);
}
}
Lens<Point, Integer> x = Lens.of(
Point::x,
Point::withX
);
Lens<Rect, Point> topLeft = Lens.of(
Rect::topLeft,
Rect::withTopLeft
);
Lens<Rect, Integer> topLeftX = compose(topLeft, x);
<OE, E, R>
Lens<OE, R> compose(
Lens<OE, E> left,
Lens<E, R> right) {
return Lens.of(
right.view.andThen(left.view),
left.store.andThen(right.store)
);
}
Как-то так (если я в порядке Function.compose не ошибся).
UPD: таки ошибся. Поправил.
Да не особо. Просто в Java нет линз в стандартной библиотеке, и именно реализацию линзы нужно писать руками — ровно один раз, в общем-то. Но потом, чтобы линзу создать надо будет сделать как-то так:
Lens<Point, Integer> x = Lens.of(
p -> p.x, // Point::getX
(p, x) -> p.x = x // Point::setX
);
List<Point> points = List.of(..points..);
OptionalInt maxX = points.stream()
.mapToInt(x::view).max();
var value = 1337;
points.forEach(point -> x.set(point, value));
Вот многословность — это да, но над этим тоже идёт какая-то работа.
динамическая адресация архива стоит на 20% дороже по сравнению со статической адресацией, но также на ~35% дешевле чем если архива нет совсем
кроме того, заявляется, что если из кода который читает архив убрать проверки доступности, то итоговая деградация производительности системы может быть ниже 20% за счёт меньшего числа ветвлений.
Ну а полагаться на то, что структура файла закрытая не приходится, я считаю. Код-то в OpenJDK, а значит открыт.
Конкретно такую штуку я тоже смогу написать вам на Java с некоторыми ограничениями (в немалой части — из-за церемоний с аннотациями типов), и она иногда тоже будет работать — но вы не сможете её как-то с особой пользой применять пока не напишете всего остального лямбда-исчисления. Если мы продолжим в этом же духе общаться, то через некоторое обозримое количество итераций я напишу вам аналог Frege.
В контексте обсуждения, что функциональное программирование можно сделать поверх объектно-ориентированного, я не наблюдаю в ситуации принципиальной проблемы, ведь всё, в чём вы меня поправляете — следствие моего незнания Хаскеля, а не невозможности сделать его аналог поверх Java.
Безотносительно конкретной ситуации, руководитель не обязан иметь какого-то определённого образования. Чтобы руководить IT компанией, совсем необязательно уметь писать код — обычно нужно уметь хорошо руководить людьми. Частью такого умения является умение нанять хороших советников, которые уже имеют достаточно компетенции, и прислушиваться к мнению нанятых советников.
Корень проблемы здесь не в образовании — у меня стойкое ощущение, что именно нарушена связь руководителя с экспертами: либо их совсем нет, либо они недостаточно компетентны, либо их мнение просто игнорируется, если мнение неудобное.
Ну например, в Китае уже давно можно присесть за картинку с Винни Пухом. И в России тенденция как бы наметилась уже.
Или вы имеете в виду "когда лично меня будут присаживать за котиков, тогда и поговорим"?
Это как раз показывает, что аудитория таких тем — обыкновенные люди, а не какие-то там специалисты в IT. Потому что как правило именно такие вот "обычные" люди почему-то просто принципиально не читают никакие мануалы, не ищут ничего в поисковиках, а любому способу получения информации предпочитают сразу задать вопрос и ждать пока лично им не ответят на него (и пофиг, что ответ на такой же вопрос был в предыдущем сообщении, продублирован в шапке темы и выплывает в модальном окне при нажатии кнопки "отправить", это всё было прокликано на автомате без включения мозга).
Композиция линз — это не "стандартная функциональная" композиция, потому что линза — это не функция. В функцию
A->Xнельзя передатьXчтобы получить на выходеA. Линза — это пара функций(A->X) + (X->A), потому для линз композиция должна быть сделана специально, согласно определению линзы, что я и сделал. Что до "стандарта", строкаright.view.andThen(left.view)в терминах Java уже вполне стандартная функциональная композиция, часть стандартной библиотеки.
Я огорчился, что шрифт в подписи так плохо подобрали. Могли же ну хотя бы скопировать буквы остальных имён.
Сработает только если постоянно следить за какими-то каналами новостей и обновлений. Очередной источник шума о событиях, которые либо неинтересны, либо вы всё равно ни на что там повлиять не сумеете.
Я в целом понимаю желание делегировать поддержку серверов с данными кому-нибудь ещё, но это приходит с непропорциональным ограничением в возможностях контроля за содержимым сервера.
Или платный куплен для очистки совести, чтобы приобрести моральное право пиратить. Это распространённый аргумент в подобных случаях. Например, покупка игры после того, как я на пиратской версии убедился, что всё устраивает. Или покупка альбома исполнителя после скачивания его через торренты.
Похоже, ваша позиция дрейфует. То вы хотите остановить на телевизоре, и потом продолжить с планшета точно с того же времени (и это считаете проблемой хранить данные локально), то с полным пофигизмом заявляете, что если не сможете что-то смотреть, то просто посмотрите что-то другое. Стриминговые сервисы по определению не дают абсолютно никаких гарантий, что вы сможете куда-то там вернуться и продолжить — у них там, может быть, право на трансляцию истекло пока вы до туалета шли. Или пучок других причин, большинство которых владельцы вам и сообщать не станут. В то время как локальные файлопомойки такую гарантию не дают только в случае физической поломки самой коробки.
Возможно, здесь такое соображение: всем тогда было скучно, и чтобы скучно не было, нужно было что-то придумать. Придумывать что-нибудь — это навык, у вас он развивался, ведь нужно сделать некоторое усилие, чтобы видеть в отломанной щепке автомобиль.
Теперь для развлечений придумывать ничего не нужно, всё уже есть готовое, берёшь и развлекаешься — следовательно, такой же навык не развивается. Может, развивается какой-то другой, а может — вообще никакого не развивается. Сейчас, по сути, первое поколение, детей, которым "не скучно", и мы не знаем, это хорошо или плохо, когда дети не скучают — покажет только время. Возможно, в будущем детей специально будут держать на "голодном пайке" в смысле развлечений, в воспитательных целях.
Ну а вообще брюзжание о том, что "дети в наше время ужасны" даже на месопотамских табличках с клинописью находили.
Лично я для измерения кода предпочитаю пользоваться линейкой.
А если серьёзно, то в нашем проекте очень похожая структура для сбора статистики, только на Java:
try (var psr = new WatchScope(<...name...>)) { }.Не хватало мне ещё звонков от техподдержки в духе "наша программа показывает, что у вас плохое качество соединения, пожалуйста, перезагрузите оборудование и перезвоните".
Что-то мне не особо верится, что "сотрудники и специальные системы" будут не из первой линии техподдержки.
Не совсем понимаю аргумент про точку. Точка — это синтаксис, не принцип.
В Java тоже можно синтаксически сделать "через точку", если
Lens.composeсделать нестатическим — тогда первый аргумент будетthis:Оба-на. Я-то думал, есть какой-то алгоритмический смысл делать вывод hex-текста без условных переходов и типичных lookup-tables. Ну там, ускорение для процессорного конвеера кратное. Интересное что-нибудь, эдакое, на острие прогресса, вот это вот всё.
А оказывается это всё просто чтоб людей "мордой ткнуть", мол, раз они не подумали что правильное решение — это в системных шрифтах копаться — то они "не настоящие программисты". Задача на смекалку, уровня трёх лампочек и круглых люков, и вообще без практического смысла. Но при запрете создавать вспомогательные массивы в программе — вы в своём решении создали гигантский по сравнению вспомогательный шрифт, загрузили его в память и потратили несколько килобайт(и это минимум, глифы в шрифтах бывают большие) места вместо жалких
size<char> * 16. То есть, вообще говоря, нарушили свои же условия. И при этом программа (hex-редактор, вроде?) потеряла пункт в настройках, который позволил бы пользователю установить такой шрифт, который ему будет удобнее.Удачи вашей компании в поисках работников. Удача вам пригодится.
И написана не на Rust. Вот это прямо очень жаль, как красиво могло быть.
Этот мой вариант вверху композицию, боюсь, не поддерживает. Потому что я заточил его под мутабельные данные — это значит, что
viewсделать можно, а чтобы сделатьstoreпридётся (из)вращаться со специально заточенными под композицию линзами, что, очевидно, не тру. Если данные иметь иммутабельными, то пойдёт веселее. Cкомпозированная линза для Rect.topLeft.x в любом случае будет иметь типLens<Rect, Integer>:Как-то так (если я в порядке Function.compose не ошибся).
UPD: таки ошибся. Поправил.
Да не особо. Просто в Java нет линз в стандартной библиотеке, и именно реализацию линзы нужно писать руками — ровно один раз, в общем-то. Но потом, чтобы линзу создать надо будет сделать как-то так:
Вот многословность — это да, но над этим тоже идёт какая-то работа.
Оба этих проекта они, ЕМНИП, приобрели с рук, и такой код — отличный пример того, как бывает, если рефакторинг делать "потом".
Я по этой ссылке вижу совсем другое:
Ну а полагаться на то, что структура файла закрытая не приходится, я считаю. Код-то в OpenJDK, а значит открыт.
Падение доходов граждан вполне могло в плане быть. Люди на пороге (или уже за чертой) бедности не особо интересуются, что там происходит в политике.