All streams
Search
Write a publication
Pull to refresh
@richman5read⁠-⁠only

User

Send message
AlexBrown А теперь ещё раз перечитайте определение «чистой» функции — ответ станет очевидным. Нет, не имеет права. По определению.
Читаюлюбые действия работающей программы, изменяющие среду выполнения. Тогда почему перезапись считается побочным эффектом, лишающим функцию ее чистоты, а создание новой копии нет (ведь новая копия — это тоже изменение среды выполнения)?

Значит чистая функция просто должна возвращать результат (ookami_kb). А перезапись или создание новой копии — это всегда сайд-эффект. Тогда почему второе в ФП принимается, а первое нет?
Хорошо, немного подробнее объясню свою точку зрения… Сайд-эффекты — это то, что мы не можем контролировать, например функция не просто вычисляет нужное нам значение, но и меняет что-то «на стороне». То есть это аналогично тому, как если бы функция зависела от какого-то стейта, который мы ей явно не передаем. А значит сайд-эффект — это тоже самое, но наоборот.
Офтоп конечно, но разве не может чистая функция менять переменную? Ведь что записать в новую ячейку памяти, что записать в уже существующую — с точки зрения сайд-эффектов выглядит одинаково…
Просто у меня свое детство
Да, это парадокс какой-то: вроде бы для целей встраиваемого ЯП скорость не должна быть критичной (обычно есть места вовне, где можно и поболее затормозить программу), но это и есть первый вопрос, который задают про эти ЯП ))
И это правильно! ФБ кушать не просит, а статистика наберется. Может и взлетит…
Я не настоящий сварщик, поэтому просто читаю об этом 1, 2, 3, 4, 5
В Rust язык потихоньку расширяется и даже переход от Rust 2015 к Rust 2018 вроде как достаточно плавный… а уже освоенные знания в тыкву превращаются небыстро.
Нет ли у вас ощущения, что для развития Rust было бы выгодно сделать как в истории с Python2->Python3? Пока еще он не сильно распространен…
Разумно… Может ваша шутка про интерес игроделов к скорости вашего ЯП не такая уж и шутка.

Вы наверняка много знаете про проблемы и пути развития встраиваемых ЯП. В этом контексте кмк будет очень эффективно (и эффектно) делать пиар для Umka.
Отказаться от него (ООП), если мы уже всё равно меняем язык… по-моему нормально.
Да не вопрос, если при этом удастся обеспечить большой пул доступных программистов ©
Наконец, родился более реалистичный пример использования Umka по его основному назначению, т. е. как встраиваемого языка.
На какой базовый ЯП (чтобы в него встраивать) ориентируетесь?
Мне нравится так:
for (int i=0;i<10;i++) {   
    printf("Hello world!");
    printf("Hello world again!");
    }  
И где голосовалка?
А куда девать обиду за первую убитую обезьяну, которая так и не дала потомства человеков? Это же сколько миллиардов людей загеноцидено? И что теперь, просто простить и забыть?! </сарказм>
Зачем? Я этого не понимаю ни как плюсовщик, ни как хаскелист.
То есть вне функциональной архитектуры кода (не архитектуры ПО, как полезного механизма, а самого кода) элементы ФП бесполезны? О-о… Недавно вот на Хабре была статья про простое ФП, где как раз идею о полезности даже элементов функционального подхода всегда и везде автор и пытался доказать (см. Заключение).
0xd34df00d: попытки скрестить ООП и ФП в таком виде — непонятно, зачем это надо
Просто Scala это неудачный пример такого скрещивания. А так-то как-раз надо! Ну и «много-стильность» Скалы тоже в ей минусы записалось. И там непривычный синтаксис — это уже просто вишенька на торте.

phtaran: у Rust синтаксис — трэш, «тушите свет, выносите окна». Это такой же важный фактор как и безопасность, просто его недооценивают
И это единственная трудность у Раста (возможно оправданная), с остальным у него все в порядке (в отличии от той-же Scala).

В любом случае, для успеха ЯП нужна массовость его использования, а здесь порог входа (в том числе синтаксис) для новых ЯП все-таки важен. Ну что-ж, будем посмотреть…
Так PHP для веба должен быть лучше, чем Java (и для маленьких, и для больших проектов).
А я не согласен: Что делает Rust универсальным языком программирования
Да, понятно, что планов громадье (и я только «за»), но важно понимать, что такой ЯП должен быть также удобен для большого количества разработчиков. Иначе будет как в Майами со Скалой.
Это системный язык, ему незачем становиться всецелевым и соревноваться с другими языками в их нишах.
Вот с этим согласен. Все-таки ручная работа с памятью и работа с бизнес-процессами — разные вещи. Целиться в: betterC + nativeJava опасно превращением в новый супер-громоздкий (или просто переусложненный) ЯП.
И история с С++ тому пример.
Согласен, что думающие люди делятся на: любящих дедукцию или индукцию. Возможно, первые даже умней вторых (фп-шники могут радоваться, разглядывая свое растущее чсв). Первые отталкиваются от слова «как?», а вторые от слова «надо!». Первые — больше ученые, вторые ближе к инженерам.
И как справедливо здесь заметили, есть еще месильщики.
Все-таки любой ЯП должен учитывать на какую категорию пользователей он направлен.

упс… ответ был на этот коммент
но все-таки сознательно делать язык, который не следует общепринятым концепциям, просто так — это как минимум странно
Так зачем делать «как было», если можно сделать лучше?
Интересно, достаточно ли будет для Майкрософта использовать только safe-часть языка Rust для своих проектов? Они же не ВЧТ HFT занимаются…

Information

Rating
Does not participate
Registered
Activity