Pull to refresh
5
0
Филипп@Filipp42

Лисп-программист

Send message

Я для работы с Unicode использую вот эту библиотеку:
https://codeberg.org/atman/zg

Полагаю, что его следует сравнивать в первую очередь с Си.
Я, с одной стороны Си люблю, с другой мне многое в нём очень не нравится. Я рад, что ему была найдена достойная замена.

И да, он безопаснее, чем C. Стандартная библиотека на порядок лучше, чем в Си. На счёт того, кто быстрее... Тут, наверное, Си немного выиграет, потому что в нём есть оптимизации на основе UB и отсутствуют многие проверки. Зато в Zig гораздо проще работать с SIMD! Но в любом случае, Zig - это очень быстрый язык. Хотя правильно написанный код на Julia может оказаться быстрее неправильно написанного кода на Zig...

Самое любимое преимущество Zig - это алгебраические типы данных. А именно, маркированное объединение (tagged union) - тип сумма. В C есть union, но он не хранит информации о том, какой именно вариант сейчас активен. В Zig union(enum) хранит тег, и его можно красиво сочетать со switch
```

const Res = union(enum) {
    node: *Node,
    fail,

    pub fn success(node: *Node) Res {
        return .{ .node = node };
    }
};
pub fn next(self: *Parser) anyerror!*Node {
        switch (try self.readInteger()) {
            .node => |node| return node,
            .fail => {},
        }
        switch (try self.readSymbol()) {
            .node => |node| return node,
            .fail => {},
        }
        switch (try self.readList()) {
            .node => |node| return node,
            .fail => {},
        }
        return ParsingError.CantParse;
    }

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

Другой большое преимущество - это comptime - вычисления во время компиляции. Он позволяет, например, делать регулярные выражения, которые оптимизируются во время компиляции. Хотя тут возникает проблема, что само регулярное выражение должно быть известно во время компиляции. Но это проблема библиотеки регулярных выражений. Можно написать и обычным образом.

А ведь в comptime можно производить вычисления над типами... Так реализованы обобщённые типы:

fn Gen(ty: type) type {
    return struct {
        first: ty,
        second: i32,
    };
}

const GenUsize = Gen(usize);

Если сравнивать безопасность Си и Zig, то побеждает конечно же Zig.
В нём все указатели, которые могут содержать Null обязательно помечаются, и если мы хотим из разыменовать, нам нужно будет их проверить, что они не Null.


fn foo(a: ?*GenUsize) void {
    if (a) |gen| { // Вот тут мы проверяем, что указатель не null, и кладём его значение в gen, если он таки не null.
        std.debug.print("First: {}, Second: {}\n", .{ gen.first, gen.second });
    } else {
        std.debug.print("No value\n", .{});
    }
}

Работа с памятью заметно улучшена, по сравнению с Си. Для выделения памяти используется специальный объект - аллокатор. Если функция решила выделить память, она должна принимать аллокатор в качестве параметра:

const std = @import("std");

/// Создаёт динамический массив целых чисел от 0 до n-1,
/// возвращает срез (slice). Вызывающий отвечает за освобождение памяти.
fn createRange(allocator: std.mem.Allocator, n: usize) ![]u64 {
    // Выделяем память под n элементов
    const slice = try allocator.alloc(u64, n);

    // Заполняем значениями
    for (slice, 0..) |*item, i| {
        item.* = @intCast(i);
    }

    return slice;
}

pub fn main() !void {
    // Используем GeneralPurposeAllocator для отслеживания утечек
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer {
        const status = gpa.deinit();
        if (status == .leak) {
            std.debug.print("Обнаружена утечка памяти!\n", .{});
        }
    }

    const allocator = gpa.allocator();

    // Вызываем нашу функцию
    const numbers = try createRange(allocator, 10);
    defer allocator.free(numbers); // освобождаем при выходе из scope

    // Печатаем результат
    for (numbers) |num| {
        std.debug.print("{} ", .{num});
    }
    std.debug.print("\n", .{});
}


Этих аллокаторов есть несколько видов, самые полезные - это GeneralPurposeAllocator и аллокатор арена.

GPA просто позволяет выделять куски памяти, а потом их освобождать. Каждый выделенный кусок нужно один раз освободить.

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

Замечательно, что аллокаторы имеют один интерфейс, так что для выделения памяти функцией можно использовать как арену, так и GPA, в зависимости от того, чего мы хотим добиться!

В Zig есть срезы (слайсы). В них хранится как указатель на массив, так и его длина. При попытке доступа к элементу может быть проверка на выход за границу массива, но это зависит от режима.

Ещё одно прекрасное преимущество Zig - это обработка ошибок. Начнём с того, что в отличие от Си она тут хотя бы есть! То, что есть в Си - не считается, это костыли и прошлый век.

В Zig под обработку ошибок выделена отдельная система. Функция может быть помечена как способная вернуть ошибку. Ошибку можно либо прокинуть вверх при помощи try, либо отловить при помощи catch. Эти ключевые слова в Zig действуют не так, как в других языках.

const MyError = error {
    Ploho, // Возможноые варианты ошибки
    Ujasno,
};

fn baz(a: usize) MyError!void { // Помечаем, что функция вернёт либо ошибку типа MyError, либо void
    if (a % 2 == 0) {
        return error.Ploho;
    } if (a % 3 == 0) {
        return error.Ujasno;
    }
}

pub fn main() void {
    try baz(1); // Просто выполнится, так-как baz не возвращает ошибку. try ничего не сделает
    baz(2) catch |err| { // Перехватываем ошибку, и что-то с ней делаем
        std.debug.print("Error: {}\n", .{err});
    };
    try baz(4); // Так-как baz вернёт ошибку, оператор try просто вернёт её из функции.


Короче говоря, Zig побеждает C по многим параметрам. Это я ещё не все перечислил. Составить ему конкуренцию могут только Rust и C++. Что же он противопоставит им? Простоту. Zig очень простой язык. Говорят, его реально, без шуток можно выучить за 21 день, если вы уже умеете программировать. Я слышал отзыв одной компании, которая использовала Zig, что ей не нужно было нанимать тех, кто его уже знает. Они могли просто научить ему программиста сами.

C++ он побеждает ещё и тем, что в Zig нет такого адского количества неопределённого поведения. А ещё в C++ куча легаси, оставшегося за пятьдесят лет развития, и он унаследовал множество недостатков Си! Его очень трудно знать хорошо.

Rust, наверное, самый сильный противник. Думаю, что многим он подойдёт больше. С другой стороны, в Zig управление памятью полностью ручное, а в Rust оно автоматическое. Часто это плюс, но я могу представить ситуацию, когда это минус. Хотя не знаю, что это за ситуацию.

И вообще, тут много вкусовщины. Мне Zig нравится больше всего. Rust я не осилил. C++ мне категорически не нравится.

Очень советую попробовать написать на Zig достаточно большую программу, чтобы почувствовать, ваш это язык, или не ваш. Если вы любите C, то скорее всего полюбите и Zig.

Скажите пожалуйста, а какое влияние на вашу операционную систему оказала Plan-9?
Я слышал, что она была эталоном архитектурной изящности, но к сожалению, не сумела завоевать популярности.

Добрый день!
Очень заинтересовал ваш проект.
Я сам написал на Zig игрушечный интерпретатор: https://github.com/Filipp-Druan/berlisp
И сейчас вернулся к написанию компилятора: https://github.com/Filipp-Druan/ftorlisp
Скажите пожалуйста, я могу что-нибудь написать для вашей ОС?
Я никогда разработкой ОС не занимался. Мне было бы интересно с этим разобраться.
Скажите, чтобы немного поучаствовать в вашем проекте, нужно ли предварительно перелопатить кучу книг?

У меня есть безумная идея.
Чем больше людей получит образование - тем лучше.

Но бывает так, что человек идёт на какую-то специальность просто потому, что надо куда-то пойти. И получает бесполезную для него специальность.

В средние века были тривиум (Грамматика, Логика, Риторика) и квадривиум (Арифметика, Геометрия, Астрономия, Музыка).

Вот мне и пришла мысль: может быть, для тех, кто не определился с тем, что они хотят, организовать что-то вроде тривиума и квадривиума? Учить их универсальным вещам. В наше время выбор предметов должен, конечно, быть другим. Например, логика, математика (не очень сложная), история, теория принятия решений.

Ещё могут очень помочь науки о тексте, только я не знаю, какие конкретно выбрать. Работа с источниками наверное. Логику уже назвал. Обязательно информатика! И не такая, где учат тыкать кнопки в Word, а такая, которая давала бы понимание работы современной инфраструктуры.

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

Я встречал критику мозгового штурма у Генриха Альтшуллера. В качестве альтернативы он предлагал выделить закономерности развития техники, и применять их целенаправленно. На этой основе была создана Теория решения изобретательских задач (ТРИЗ). Кто-то говорит, что она решает кучу проблем и очень полезна. Кто-то говорит, что она бесполезна. Я склоняюсь к тому, что это довольно интересная эвристика, которую не плохо бы знать. Хотя я не применял её на практике... Говорят, в программировании её применить не получалось. Есть свидетельства, что сам Альтшуллер утверждал: чтобы освоить ТРИЗ, нужно много часов лекций и куча решенных задач. Так по книгам учить не особо полезно.

Есть ещё такой интересный эффект как гроконие (Grokking). Это когда модель обучается на маленьком датасете, полностью его выучивает, но тестовая точность остаётся очень низкой. Но потом, если оставить модель обучаться очень и очень долго, то качество тестовой выборки подскакивает почти до ста процентов. Модель обобщает после долгого запоминания.

Интересно, а они выпустят Gemma 4? Я вот этого очень жду.

Хм... Интересно. А если рисовать перед генерацией шаблон-аниматик, который задаёт темп, повороты камеры, тому подобное. А диффузия после этого генерирует основное видео.

Мне хочется очень высокого качества.
Эх, мечты...
Хотя, с другой стороны, у нас довольно много авторской анимации.
Хотя её в основном делают люди причастные к ремеслу.

Спасибо!
Мне бы узнать конкретные приёмы.
Тут дело в том, что мне хотелось бы достичь достаточно реалистической рисовки. И консистентность очень важна. Хотелось бы достигнуть студийного уровня картинки. Мечты мечты...
Другое дело, что у меня нет режиссёрского образования. И я мало смотрю сериалы. Да что там, вообще не смотрю.

Это мне сказал один режиссёр.
А у вас есть другие данные?

Добрый день!
Скажите пожалуйста, а есть ли какой-нибудь способ изначально снизить вероятность заражения?
Может быть, можно изначально пропесочить модель в промпте, чтобы она не давила на эмоции, проявляла трезвость и сдержанность?

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

Мне это конечно нравится, но мне нужна истина, точная оценка, которая поможет мне действовать.

Можете подсказать что-то, что поможет использовать ЛЛМ на пользу?

А можете рассказать, как это выглядит на практике? Какие конкретно это проект?

Не скажите!
Клауди Опус очень знатно нарисовал мне шарико-подшипник.

Хм... Я мечтаю написать на Zig библиотеку вроде LLVM - для построения компиляторов.
Как вы думаете, если я выполню несколько таких проектов, можно ли меня будет считать мидлом?
Вообще, опыт разработки опен-сорс считается за опыт в компании?

Добрый день!
Скажите пожалуйста, а что делать обычным джунам?
Я не работал в компании ни дня.
И я трачу время на непопулярные языки: Zig, Lisp.
Как мне попасть на работу?

По блату?

Это какую модель для генерации они используют? Это лучше чем нано банана. Или вы просто выбрали лучшие примеры из многих?

Information

Rating
5,073-rd
Registered
Activity