Ну если честно это какой-то антипаттерн. Синтаксис такой, какой он есть и конечно лучше бы ему следовать. У меня например была перегрузка точки, чтобы свойства объектов можно было получать и назначать вот так obj1.Name и obj1.Name = "Name", но отказался от этого чтобы не ломать лишнего.
И так к перегрузке деления. В WL нет никакого деления и сделать конкретно то, что вы показали выше чуть-чуть сложнее чем кажется, но возможно:
А прием здесь демонстрации? Они все были сделаны примерно в одно время, когда WRI придумали CDF и решили сделать сайт с кучей примеров. А лучший пример - это визуализация
Но ведь все это есть, просто оно выглядит необычно и нужно привыкнуть. Но это в любом языке так. С ООП только спорно, но матируемый объекты с наследованием я сделал сам
Я все таки пытаюсь выяснить про что-то, что есть в популярных языках чего вам не хватает. Я лично раньше все время хотел, чтобы была возможность писать веб-приложения на WL. Теперь я сам это сделал и оно работает. А вам чего не хватает? На Python тоже не пишут ядро операционной системы, но он считается языком общего назначения и есть области где он хорош, а где не очень.
как писал @JerryI, на данный момент не смотря на все проблемы и сложности существуют пакеты для WL, которые позволяют писать веб-приложения, ботов для различных приложений, анализировать данные, тренировать нейросети и др... то есть я хочу сказать что силами энтузиастов постепенно в языке появляется то, что интересно программистам и то, что делает WL языком общего назначения. Вот вам чего не хватает чтобы пользоваться WL как языком общего назначения?
Так быстро мне трудно сказать, но в WL есть очень крутая штука, которая называется StringExtression. Например такой код проверят что строка соответствует шаблону по первому слову:
В строковые выражения имеют примерно такой же функционал как и регулярные выражения, но для меня, так как я ими чаще пользуюсь они более читабельны и позволяют более универсальный код писать для разбора строк.
Может быть позже я напишу про них отдельную статью
Если есть бесконечная рекурсия - ядро в какой-то момент выдает сообщение о том, что лимит рекурсии исчерпан. Если есть бесконечный цикл, который не удается определить как рекурсию - то вычисления так и будут висеть бесконечно. Это является ответственностью пользователя. Конечно хочется чтобы такое предотвращалось, но вот такой принцип языка
На самом деле цена действительно очень высокая. Ведь если вы хотите пользоваться всегда новой версией, то придется покупать заново лицензию раз в 1-2 года. Велосипед послужит намного дольше
А можете пожалуйста рассказать какого рода проблемы у вас чаще всего приводили к падению ядра и привести пример кода или хотя бы показать какую задачу вы решали? Ну и про потребление памяти тоже хотелось бы подробнее
В качестве рассуждения, я могу сказать, что вы всегда можете реализовать один собственный символ - Combinator и повесить на него все ограничения связанные с комбинаторной логикой в том виде, какая она есть в Lisp. Но почему нельзя создавать определения в процессе выполнения и чем опасны Print, Module, Function и Set?
Те примеры, которые вы описали вполне выполнятся в WL и будут работать прям в таком виде. Вам ничто не мешает писать практически так же на WL. Разве что указать, подчеркивание добавить, чтобы указать, что x - аргумент.
Вот допустим вы задаете комбинатор и говорите, что при его встрече CL возвращает другой комбинатор. Так это ведь в точности тоже самое, что и правила замены, просто там больше синтаксического сахара и может быть больше одного аргумента.
Я люблю холивары про стили, парадигмы и подходы программирования. Паттерн-матчинг не является синонимом ФП. Главный принцип ФП насколько я понимаю - это акцент на функциях, который обрабатывают данные. Еще важно, что данные неизменяемы - то есть они не могут мутировать как объекты, а функции всегда стабильно возвращают результат. То есть мутирующая операция на изменяемом объекте будет каждый раз менять состояние системы, а преобразование одних данных в другие функцией не должны ничего менять и обязаны что-то возвращать. Нигде я не видел паттерн-матчинг как обязательное условие ФП. Все что я описал выше работает в JS. Вы сами писали - парадигма - это то, как пишет программист. На JS если следить за руками можно легко писать функции, которые не будут ничего мутировать и однозначно возвращать результат. Его поэтому так любят там применять, потому что например в DOM возникает слишком много путаницы если каждая функция будет заниматься мутированием вместо простых и четких преобразований, в которых программист уверен
Все таки я вас не понял. Если ФП или Символьное Программирование - это про то как программист оформляет свой код, то на JS стопроцентно можно писать как на ФП.
В статье я показал сначала как пользователь может использовать символьное программирование, а затем продемонстрировал, что само ядро работает точно так же. Может чтобы избежать путаницы стоит называть это символьным исчислением
только надо чтобы In[151] выполнялся после In[153], я выполнил несколько раз - поэтому у меня сработало
Ну если честно это какой-то антипаттерн. Синтаксис такой, какой он есть и конечно лучше бы ему следовать. У меня например была перегрузка точки, чтобы свойства объектов можно было получать и назначать вот так
obj1.Name
иobj1.Name = "Name"
, но отказался от этого чтобы не ломать лишнего.И так к перегрузке деления. В WL нет никакого деления и сделать конкретно то, что вы показали выше чуть-чуть сложнее чем кажется, но возможно:
Чем мог! ?
Когда смогу постараюсь высказать свои мысли про остальное
Мы не использовали SocketListener, но его тоже можно использовать в текущей реализации. Но спору нет - без него бы веб-сервер не получился
А прием здесь демонстрации? Они все были сделаны примерно в одно время, когда WRI придумали CDF и решили сделать сайт с кучей примеров. А лучший пример - это визуализация
Пожалуй про это стоит написать отдельно небольшое руководство.
Но ведь все это есть, просто оно выглядит необычно и нужно привыкнуть. Но это в любом языке так. С ООП только спорно, но матируемый объекты с наследованием я сделал сам
Я все таки пытаюсь выяснить про что-то, что есть в популярных языках чего вам не хватает. Я лично раньше все время хотел, чтобы была возможность писать веб-приложения на WL. Теперь я сам это сделал и оно работает. А вам чего не хватает? На Python тоже не пишут ядро операционной системы, но он считается языком общего назначения и есть области где он хорош, а где не очень.
как писал @JerryI, на данный момент не смотря на все проблемы и сложности существуют пакеты для WL, которые позволяют писать веб-приложения, ботов для различных приложений, анализировать данные, тренировать нейросети и др... то есть я хочу сказать что силами энтузиастов постепенно в языке появляется то, что интересно программистам и то, что делает WL языком общего назначения. Вот вам чего не хватает чтобы пользоваться WL как языком общего назначения?
Скажите пожалуйста, в какой главе этой книги написано про шаблоны и правила замены?
Так быстро мне трудно сказать, но в WL есть очень крутая штука, которая называется StringExtression.
Например такой код проверят что строка соответствует шаблону по первому слову:
А вот такая штука вырежет текст из разметки XML:
Вот такой проверит на соответствие простому номеру телефона:
В строковые выражения имеют примерно такой же функционал как и регулярные выражения, но для меня, так как я ими чаще пользуюсь они более читабельны и позволяют более универсальный код писать для разбора строк.
Может быть позже я напишу про них отдельную статью
Если есть бесконечная рекурсия - ядро в какой-то момент выдает сообщение о том, что лимит рекурсии исчерпан. Если есть бесконечный цикл, который не удается определить как рекурсию - то вычисления так и будут висеть бесконечно. Это является ответственностью пользователя. Конечно хочется чтобы такое предотвращалось, но вот такой принцип языка
На самом деле цена действительно очень высокая. Ведь если вы хотите пользоваться всегда новой версией, то придется покупать заново лицензию раз в 1-2 года. Велосипед послужит намного дольше
А можете пожалуйста рассказать какого рода проблемы у вас чаще всего приводили к падению ядра и привести пример кода или хотя бы показать какую задачу вы решали? Ну и про потребление памяти тоже хотелось бы подробнее
Да
В качестве рассуждения, я могу сказать, что вы всегда можете реализовать один собственный символ - Combinator и повесить на него все ограничения связанные с комбинаторной логикой в том виде, какая она есть в Lisp. Но почему нельзя создавать определения в процессе выполнения и чем опасны Print, Module, Function и Set?
Те примеры, которые вы описали вполне выполнятся в WL и будут работать прям в таком виде. Вам ничто не мешает писать практически так же на WL. Разве что указать, подчеркивание добавить, чтобы указать, что x - аргумент.
Вот допустим вы задаете комбинатор и говорите, что при его встрече CL возвращает другой комбинатор. Так это ведь в точности тоже самое, что и правила замены, просто там больше синтаксического сахара и может быть больше одного аргумента.
Я люблю холивары про стили, парадигмы и подходы программирования. Паттерн-матчинг не является синонимом ФП. Главный принцип ФП насколько я понимаю - это акцент на функциях, который обрабатывают данные. Еще важно, что данные неизменяемы - то есть они не могут мутировать как объекты, а функции всегда стабильно возвращают результат. То есть мутирующая операция на изменяемом объекте будет каждый раз менять состояние системы, а преобразование одних данных в другие функцией не должны ничего менять и обязаны что-то возвращать. Нигде я не видел паттерн-матчинг как обязательное условие ФП. Все что я описал выше работает в JS. Вы сами писали - парадигма - это то, как пишет программист. На JS если следить за руками можно легко писать функции, которые не будут ничего мутировать и однозначно возвращать результат. Его поэтому так любят там применять, потому что например в DOM возникает слишком много путаницы если каждая функция будет заниматься мутированием вместо простых и четких преобразований, в которых программист уверен
Все таки я вас не понял. Если ФП или Символьное Программирование - это про то как программист оформляет свой код, то на JS стопроцентно можно писать как на ФП.
В статье я показал сначала как пользователь может использовать символьное программирование, а затем продемонстрировал, что само ядро работает точно так же. Может чтобы избежать путаницы стоит называть это символьным исчислением