Комментарии / Профиль tenzink / Хабр

; Даны два массива целых чисел произвольной длины.\
; Найди их пересечение с учётом повторяющихся элементов.\
; Порядок элементов в результате не важен.\
;
; Первый массив: [1, 2, 3, 2, 0, 2]
; Второй массив: [5, 1, 2, 7, 3, 2]
; Результат: [1, 2, 2, 3]

подключи список
подключи математику

функция возьми_первый_массив(): список[целых] = (
    (1 2 3 2 0 2)
)

функция возьми_второй_массив(): список[целых] = (
    (5 1 2 7 3 2)
)

функция выполни(): список[целых] = (
    функция найди_общие_значения(): список[целых] = (
        верни (
            возьми_первый_массив()
            |> список.оставь_без_повторов()
            |> список.пересеки_с(
                возьми_второй_массив()
                |> список.оставь_без_повторов()
            )
        )
    )

    функция посчитай_вхождения(
        значения: целое
        в_массиве: список[целых]
    ): целое = (
        верни (
            в_массиве
            |> список.оставь(
                функция проверь(
                    элемент: целое
                    по_индексу: целое
                ): логическое = (
                    элемент = значения
                )
            )
            |> список.посчитай()
        )
    )

    функция сопоставь_значения_с_кратностью():
        список[пар[целых]]
    = (
        верни (
            найди_общие_значения()
            |> список.преобразуй(
                функция сопоставь(
                    значение: целое
                    по_индексу: целое
                ): пара[целых] = (
                    (
                        значение
                        математика.выбери_меньшее(
                            посчитай_вхождения(
                                значения: значение
                                в_массиве: возьми_первый_массив()
                            )
                            посчитай_вхождения(
                                значения: значение
                                в_массиве: возьми_второй_массив()
                            )
                        )
                    )
                )
            )
        )
    )

    верни (
        сопоставь_значения_с_кратностью()
        |> список.сверни(
            функция добавь(
                в_результат: список[целых]
                значение_с_кратностью: пара[целых]
                по_индексу: целое
            ): список[целых] = (
                функция повтори_значение(): список[целых] = (
                    верни список.повтори(
                        значение: значение_с_кратностью[0]
                        раз: значение_с_кратностью[1]
                    )
                )

                верни список.соедини(
                    в_результат
                    с: повтори_значение()
                )
            )
            начиная_с: ()
        )
    )
)

выполни()

Пишу русскоязычный ЯП. Помогите выбрать самый читаемый вариант синтаксиса

tenzink 14 авг в 06:15

Русский язык - отдельное спорное решение.

Начнём с "эффекта зловещей долины". Код типа такого `список сложить(один, два, три)` лично у меня вызывает только брезгливость. Если это русский, то пусть будет хотя бы `сложи список (...)`. Иначе это воспринимается как безграмотность и издевательство над русским языком.

С практической точки зрения кодировать неудобно. Вероятней всего не избежать частого переключения раскладок.

И тут уже кто-то приводил аргумент, что язык математики не локализуют (синус, интеграл, и т.п.). Мне симпатична такая аналогия

Пишу русскоязычный ЯП. Помогите выбрать самый читаемый вариант синтаксиса

tenzink 13 авг в 17:53

Поскольку критериев выбора синтаксиса у вас всё равно нет, то рекомендую посмотреть ещё в одну сторону. Самый красивый синтаксис который я видел, это в семействе ML-языков (Ocaml, Standard ML of New Jersey) или на худой конец в Haskell

Claude Opus 5 удалила данные пользователя вместо создания резервной копии с помощью «rm -rf» для всего диска на ПК

tenzink 7 авг в 17:15

В очередной раз о пользе plan mode и проверкой вручную или с помощью другой модельки

Невероятно быстрый алгоритм нахождения простых делителей огромных составных чисел

tenzink 5 авг в 11:30

Ну ok, раз речь про "Невероятно быстрый алгоритм нахождения простых делителей огромных составных чисел", то сколько ваш алгоритм будет факторизовать вот такое не слишком огромное число?

3597284440855924544760705321078319513881289134853978802171066623680480235229732988761104885629809631999005054189544840315407267231713401943322212324974300752954681286642512935564763772827324008300407016109060076912152536812782569409805382513070413043

Скрытый текст

Число получено как перемножение вот этих двух чисел из интернета (гугл говорит, что оба простые)

a=5280842695870597262871829916036347793181048105944727626357078127619420046530136938413905659102954019
b=681195151612611689484381505082728530227937846992253495686317828427132018802795367772173239804088945451030304776802491083558288394588076833648046982897

Группу подростков‑туристов пришлось спасать на вертолёте из‑за ошибки Google Maps

tenzink 4 авг в 06:22

Не факт. Им вполне могли выкатить счет. Не знаю их конкретный случай, но сомневаюсь, что у там была страховка с включенной эвакуацией вертолетом

Группу подростков‑туристов пришлось спасать на вертолёте из‑за ошибки Google Maps

tenzink 3 авг в 10:19

Скачивайте карты мира от Генштаба СССР. Они уже 80 лет как не устаревают.

Ещё как устаревают, даже без учёта хозяйственной деятельности челокека. Из самого заметного тают ледники, что влияет на тропы и сложность маршрутов. Появляются/исчезают озёра, меняются русла рек, переправы

Английский вместо кода

tenzink 3 авг в 09:10

А поделитесь примерами? Такое не на слуху, интересно было бы посмотреть

Группу подростков‑туристов пришлось спасать на вертолёте из‑за ошибки Google Maps

tenzink 3 авг в 09:07

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

Группу подростков‑туристов пришлось спасать на вертолёте из‑за ошибки Google Maps

tenzink 3 авг в 08:48

Даже если они расчитывали на 5ч прогулку, поллитра на человека это очень мало. Хорошо, хоть хватило ума развернуться и вызвать спасателей

Детектор жизни

tenzink 1 авг в 14:38

Лесной пожар, кажется, тоже подходит под ваше определение живого.

Почему C++ или Rust никогда не смогут заменить Python

tenzink 30 июл в 06:32

Стандарт C++98 короче. А вот код, сопоставимый по производительности и функционалу, будет более многословным и намного менее читабельным по сравнению с C++11/14/... Потребуется возвращать результат через выходные параметры, работать с индексами или итераторами для обхода коллекции, явно прописывать типы в прикладном коде. В общем - страшный сон, который хочется поскорее забыть.

Если современный C++ позволяет писать код, приближающийся по читабельности к python, то C++98 недостаточно выразителен - там приходится страдать и писать кучу обслуживающего кода, не относящегося напрямую к логике алгоритма

Почему C++ или Rust никогда не смогут заменить Python

tenzink 29 июл в 07:47

Смена компилятора, даже внутри одной линейки, это сложно для нетривиальной кодовой базы. Ошибки компиляции только вершина айсберга, да и бороться с ними не так сложно. Гораздо опасней UB, которые могут проявляться по разному. То есть код успешно будет собираться, но приложение собранное одном компилятором работает "нормально", а собранное другим периодически крешится

Это в большей степени не про обратную совместимость, хотя и в рамках одной линейки компиляторов от версии к версии подобные приколы бывают. Лечится только тестированием сборок под разными компиляторами, санитайзерами, статическими анализаторами и т.п.

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

Почему C++ или Rust никогда не смогут заменить Python

tenzink 28 июл в 10:44

Давно, будучи студентом, наткнулся на такой язык, как Standard ML of New Jersey. Помню, что это был эстетический восторг.

Он не слишком известен и скорее академический. Из ближайших родственников - это OCaml. Семейство ML-языков сильно повлияло на Haskell / F# и на индустрию в целом (алгебраические типы, Continuation‑Passing Style, вывод типов Hindley‑Milner и т.п.). Интересно наблюдать, как через десятки лет идеи оттуда проникают, трансформируясь по пути, в современные mainstream языки (Rust/C++/Python/Kotlin/...).

Интересно было бы пофантазировать, каково изучать в качестве первого языка что-то типа OCaml.

Почему C++ или Rust никогда не смогут заменить Python

tenzink 28 июл в 09:32

В том-то и дело, что полный код и на Rust, и на C++ будет безусловно сложнее, но не там, где ищет автор статьи.

Заметно усложнится библиотечный код - и большая часть боли будет там. Появятся нетривиальные сигнатуры, потребуется явно продумать систему типов, преобразования типов ошибок и т.п. В случает плюсов отдельная боль будет, чтобы настроить сборку и просто всё собрать со всеми зависимостями

Почему C++ или Rust никогда не смогут заменить Python

tenzink 28 июл в 09:13

И в Rust, и в C++ ничего дополнительно делать не нужно. Уже в псевдокоде всё работает "из коробки" - ошибки уже корректно обрабатываются:

В C++, как и в python, кидается exception
В Rust стандартный возврат результата через Result: https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#the--operator-shortcut

Почему C++ или Rust никогда не смогут заменить Python

tenzink 28 июл в 07:43

При понятном посыле статьи, примеры на C++/Rust притянуты за уши. Раз уж тут псевдокод, то ловите функциональный аналог питоновской версии на C++

for( const auto& batch : dataloader) {
    auto logits = classifier(batch.features);
    auto loss = cross_entropy(logits, batch.labels);
    loss.backward();
    optimizer.step();
}

и на Rust

  for batch in dataloader {
      let logits = classifier.forward(&batch.features)?;
      let loss = cross_entropy(&logits, &batch.labels)?;
      /// ...
  }

+21

2 3 ...

40 41