The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Линус Торвальдс не исключил возможность интеграции поддержки Rust в ядро Linux 5.20, opennews (ok), 22-Июн-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


85. "Линус Торвальдс не исключил возможность интеграции поддержки..."  –3 +/–
Сообщение от n00by (ok), 22-Июн-22, 12:42 
> Раст болтливый язык? Одинаковая реализация в процедурном стиле среднестатистического
> алгоритма на чистом Си будет занимать меньше строк чем на Расте?

Раст, внезапно, функциональный. Так что, в общем случае, меньше. Другое дело, что железо "императивно".

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

258. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (258), 23-Июн-22, 11:22 
> Раст, внезапно, функциональный.

в расте функции - первоклассные объекты, можно ими жонглировать как душе угодно?

Ответить | Правка | Наверх | Cообщить модератору

260. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 23-Июн-22, 12:43 
>> Раст, внезапно, функциональный.
> в расте функции - первоклассные объекты,

Если верить Википедиям, то и Си++ они первоклассные https://en.wikipedia.org/wiki/First-class_function#Language_...

> можно ими жонглировать как душе угодно?

Он же компилируемый - так что есть нюансы с eval. Через пару лет можно будет оформить в виде llvm.ko.

Зато "переменные" иммутабельны по умолчанию, не требуется императивный return.

Вот обычные для ФЯ конструкции:

    let y = {
        let x = 3;
        x + 1
    };

fn five() -> i32 {
    5
}

https://doc.rust-lang.org/book/ch03-03-how-functions-work.html

Осталось прикрутить к этой безусловно полезной абстракции отображенные в память регистры контроллера...

Ответить | Правка | Наверх | Cообщить модератору

286. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (258), 23-Июн-22, 15:00 
> Вот обычные для ФЯ конструкции:

Уровень детсада. Где передача функций, как объектов, каррирование, композиция функций и прочая ненизкая математика?

Ответить | Правка | Наверх | Cообщить модератору

291. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 23-Июн-22, 15:34 
>Уровень детсада.

В системном программровании нужна только процедурщина.

>Где передача функций, как объектов, каррирование, композиция функций и прочая ненизкая математика?

А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном программировании не нужна.

Ответить | Правка | Наверх | Cообщить модератору

299. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 23-Июн-22, 16:25 
> А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном
> программировании не нужна.

Смысл функционального программирования не в этих всех замыканиях. Если процедура хранит состояние, то для одних и тех же входных данных она может давать различный результат. Отсюда следует идея чистых функций и иммутабельности: если состояние не хранить, тогда можно на этапе трансляции доказать корректность кода -- как раз это в Rust и называют "безопасность". По той же причине в императивных языках по возможности стараются писать const. Но в реальном железе имеем const volatile. =)

Ответить | Правка | Наверх | Cообщить модератору

444. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 13:00 
> в реальном железе имеем const volatile. =)

Это что еще за порнография? Типа регистр RO для софта, но который может со своей стороны менять железо?

Ответить | Правка | Наверх | Cообщить модератору

455. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 26-Июн-22, 13:25 
>> в реальном железе имеем const volatile. =)
> Это что еще за порнография? Типа регистр RO для софта, но который
> может со своей стороны менять железо?

Это когда регистр железно выполнен как RO, софт может туда и писать, но ничего не изменит.

Ответить | Правка | Наверх | Cообщить модератору

470. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/–
Сообщение от Аноним (-), 26-Июн-22, 17:03 
> Это когда регистр железно выполнен как RO, софт может туда и писать,
> но ничего не изменит.

А, обычный RO регистр, что-то я тупанул тут. Вообще регистры логично референсить как адреса в памяти, то-бишь указатели, и там чуть сложнее получается - const'ов может быть ДВА. У указателя (как индикатор что адрес регистра прибит на гвозди, зачем нам баги если мы сдуру указатель сменим?!) - и потом у его типа. Как бы именно volatile const'ом регистр вообще не референсится, скорее указателем на него.

Хотя-бы потому что убедить си кинуть переменную в памяти по конкретному адресу... как бы это... ну, не предусмотрено. А с указателями пожалуйста.

Интересно как хрустики кстати volatile делают и вот это самое, раз кудахчут про системность.

Ответить | Правка | Наверх | Cообщить модератору

442. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:58 
> В системном программровании нужна только процедурщина.

А ты уверен что даже просто ioctl какой попадает под именно такое определение? :)

А еще - в сях можно функции переназначать на лету, передавать как параметры и проч. Указателями на функцию, прикинь?! Это позволяет делать довольно забавные вещи.

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

>>Где передача функций, как объектов, каррирование, композиция функций
>>и прочая ненизкая математика?
> А зачем вся эта порнуха нужна системному программированию. Ненизкая математика в реальном
> программировании не нужна.

Они половину этой порнухи так то сами умеют делать прямо из сей каких и проч.

Ответить | Правка | К родителю #291 | Наверх | Cообщить модератору

298. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 23-Июн-22, 16:07 
>> Вот обычные для ФЯ конструкции:
> Уровень детсада. Где передача функций, как объектов, каррирование, композиция функций
> и прочая ненизкая математика?

Наберите интересующие слова в поисковике и читайте. Как должно быть понятно из первой ссылки, которую Вы заботливо вырезали при цитировании, там всё это можно найти. Я лишь намекаю, что функциональное программирование это не только лямбда исчисление.

Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

301. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (258), 23-Июн-22, 16:30 
> Я лишь намекаю, что функциональное программирование это не только лямбда исчисление.

Еще один невзрослый тезис. Не надо приравнивать некоторые элементы ФП и само ФП.
Функциональное программирование - это именно жонглирование функциями.

Как в расте передать композицию функций, особенно вернуть как результат, особенно с захватом локальных значений?

Ответить | Правка | Наверх | Cообщить модератору

339. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 24-Июн-22, 07:34 
> Функциональное программирование - это именно жонглирование функциями.

Поскольку "жонглирование" не формализовано, процитированное "определение" ФП - демагогическая чушь. Поскольку цирковой термин повторяется дважды - похоже на мантру для некоей секты.

Ответить | Правка | Наверх | Cообщить модератору

347. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 24-Июн-22, 10:01 
> "определение" ФП - демагогическая чушь

Вот именно, сегодня. Сегодня "определение" ФП - это "парадигма", что есть не формальное определение, а демагогия. Сегодня любой новый модный молодежный язык, в котором есть термин "функция" - это "язык ФП". А вот раньше трава была зеленее.

Ответить | Правка | Наверх | Cообщить модератору

353. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 24-Июн-22, 10:44 
То есть предмет спора выдуман автором сообщения №258.
Ответить | Правка | Наверх | Cообщить модератору

348. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 24-Июн-22, 10:04 
Вернемся к нашим баранам.
Так как вернуть композицию функций в расте?
Ответить | Правка | К родителю #339 | Наверх | Cообщить модератору

351. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 24-Июн-22, 10:40 
Ответьте, пожалуйста, отдельным сообщением, когда Вам удастся с Вашими баранами разобраться. Очень интересны вопросы животноводства.
Ответить | Правка | Наверх | Cообщить модератору

481. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (480), 26-Июн-22, 23:02 
Простите, ваша фамилия случайно не Головин?
Ответить | Правка | К родителю #348 | Наверх | Cообщить модератору

435. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 26-Июн-22, 12:40 
> Он же компилируемый - так что есть нюансы с eval. Через пару
> лет можно будет оформить в виде llvm.ko.

Чочо, модуль на 60 метров, да еще на плюсах? Ух блин нет, за это Торвальдс таки все же прилюдно люстрирует, имхо :)

Ответить | Правка | К родителю #260 | Наверх | Cообщить модератору

447. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от n00by (ok), 26-Июн-22, 13:12 
>> Он же компилируемый - так что есть нюансы с eval. Через пару
>> лет можно будет оформить в виде llvm.ko.
> Чочо, модуль на 60 метров, да еще на плюсах? Ух блин нет,
> за это Торвальдс таки все же прилюдно люстрирует, имхо :)

Так это будет потом. Когда привыкнут, что Rust уже и так есть, выйдет версия 2.0. Окно Овертона же.

Ответить | Правка | Наверх | Cообщить модератору

489. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/–
Сообщение от Аноним (-), 27-Июн-22, 17:37 
> Так это будет потом. Когда привыкнут, что Rust уже и так есть,
> выйдет версия 2.0. Окно Овертона же.

Скорее, научат хруст eBPF какой генерить и в юзермод вывесят :))). Но между нами, вон там LLVM или кто еще GPUшке в юзермоде шейдеры как-то так и компиляет.

Теоретически, это может быть безопасно. Практически, как-то наподобие трахнули xbox360, чтоли, поклав на многоэтажную систему DRMной секурити...

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру